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Field of the Invention 

The present invention relates to an electronic publishing system, and in particular to 
an electronic publishing system for the delivery of information which is not limited as to 
15 storage space and is not governed by predetermined pathways. 

The present invention relates generally to an electronic publishing system and, in 
particular, to aids for navigating in an electronic publishing system and a method of 
organising data in an electronic publishing system. 

20 Background 

Conventionally, information is published in document form as a printed 
publication, or in electronic form but again using the document or book metaphor. In the 
past, the concept of a "multidimensional space" in electronic publishing has been 
intuitively understood (that is, instinctively desired). However, a comprehensive display, 
25 discussion or treatment has been rejected by publishers and information providers as too 
difficult to develop and manage. Instead, publishers and information providers have 
managed large amounts of data: 

(1) by limiting the size or coverage of the information space; and 

(2) by setting or predetermining the path through that information space. 
30 The effect of this is clearest when the dimension of time is considered. The 

conventional approach to information storage and publishing is centred on the notion that 
information is either "current information" (ie, present day) or "historical information" (ie, 
the day before the present day and all days prior to that). Thus, information is traditionally 
retained (stored) and/or published (sold) as either current or historical information. 



The effect of this has been to leave the end user with a collection of non- integrated 
repositories and many additional tasks to do before the information is useful to them. For 
example, the end user is required to: 

(1) make most of their own connections between related pieces of information; 
5 (2) do their own analysis of the type and subject of information they require or are 

seeking; and 

(3) find information appropriate to the point in. or period of, time with which they 
are concerned. 

To illustrate the disadvantages of conventional publishing systems, an example of 
10 using such conventional techniques and publishing systems to research information is 

provided. If a person were interested in information regarding the powers of the Secretary 
under Australian legislation with respect to couples in a family relationship, when and 
how the Secretary is restricted, and what did the relevant legislation provide prior to that, 
the person would refer to relevant legal information, which is the Social Security 
15 legislation of the Commonwealth of Australia. The relevant provisions are set forth in 
Appendix A under the heading "Example Research". This would be determined by the 
end user's own knowledge of the broad subject and/or reference to secondary material. 

The relevant legislative provision is Section 4, which in conventional electronic 
legal publishing systems might be found by looking for words or phrases such as "family". 
20 "family relationships", and "family relationships" AND "social security", where AND is a 
logical operator. 

Once the above is established, it can be seen from the information found that 
Section 4 of the Social Security Act, as at 9/8/96. has been amended ten times (see 
Appendix A: AL AMENDMENTS TO SECTION AT 9/8/96), 

25 There is however nothing in the current Commonwealth Government Reprint, in 

either the electronic or print versions (see heading EXAMPLE RESEARCH of Appendix 
A), that allows the end user to see the text of those amendments or what part(s) of Section 
4 were changed by them. 

Thus, unless the end user is prepared to refer to many statute books, reading each 

30 piece of text against another, the end user is not able to see easily or reliably what section 
4 looked like before it was amended by any one of a number of prior amending Acts. 
However, if the end user has a library complete enough to provide access to the prior 
amending Acts, the person would eventually determine that Act No 105 of 1995 is the 
relevant amending Act. 
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Further, it should be noted that, while the Commonwealth Government Reprint 
indicates that the Social Security Act was amended by Act No 105 of 1995, it does not 
indicate what section or schedule in Act No 105 of 1995 actually amended Section 4. This 
again requires the end user to have access to the amending Acts themselves and renders 
5 the information provided bv the Reprint as to commencement (see Appendix A: B. 
COMMENCEMENT INFORMATION FOR ACT NO 105 OF 1995 CONTAINED IN 
REPRINT) of little utility without a copy of the amending Act No 105 of 1995 from which 
it can be established that Section 14 of Act No 105 amended Section 4 of the Social 
Security Act with respect to powers of the Commissioner (see Appendix A: D. 
AMENDING ACT 1995 NO 105 AMENDING SECTION 14Y 

Eventually, the required information can be found but several pieces of 
information need to be searched bv the end user. This is an arduous, time consuming, 
tedious and complex task that must be manually repeated for each research topic and if the 
same search is to be carried out again. 

Conventional publishing systems, including electronic publishing systems that 
typically are speeded-up, paper-based publishing systems, are based on a book- metaphor. 
The smallest piece of information used by such conventional publishing systems is either 
(D an Act or Regulation (in the case of reprints, a whole Act or Regulation is printed 
again), or (II) a word. Typically, conventional publishing systems choose a word as the 
20 smallest piece when legislation is amended. To track such amendments, a lawyer or their 
assistant may actually use scissors to cut and paste pieces of legislation or the publisher 
cuts and pastes each word electronically. If a whole Act or Regulation is tracked as in (I) 
above, it is necessary to store each new version of an Act or Regulation in its entirety. 
This has a number of consequences, including: 
25 a) only a few versions of each Act or Regulation are stored; 

b) the end user rarely searches more than one reprint at a time; 

c) it is very difficult to know which particular section or schedule has changed, to 
track how that particular section or schedule has changed, to find the relevant section of 
the Amending Act or Regulation that effected the section or schedule as shown in the 

30 reprint; 

d) if multiple changes have occurred on a particular section or schedule between 
reprints, the latest version of the section or schedule can only be seen in the reprint; 

« 
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e) issues like commencement of the latest version of a particular section or 
schedule and so-called "Application, Saving or Transitional Provisions" are difficult to 
recreate; and 

f) it is difficult to come to a full understanding of the legislation by means of the 
5 reprints. 

If every single word is tracked, as in (II) above, a level of complexity results that is 
difficult to administer and maintain without a large number of errors. For example, some 
legislative sections and schedules are amended several times annually. 

Table 1 provides an example where Section 6 of the Income Tax Assessment Act 
10 has been amended 70 times: 

TABLE 1 

S. 6 am. No. 88, 1936: No. 30, 1939; No. 50, 1942; 

No. 3. 1944; No. 6, 1946; No. 44, 1948; No. 48. 

1950; No. 1. 1953; No. 65. 1957; No. 55. 1958; 

No. 85. 1959; Nos. 18 and 108. 1960; No. 17. 1961; 

15 No. 69, 1963; No. 1 10, 1964; No. 103, 1965; 

No. 85. 1967; Nos. 4. 60 and 87. 1968; No. 93. 1969; 

No. 54, 1971; Nos. 51 and 164, 1973; No. 216. 1973 

(as am. by No. 20. 1974); No. 126. 1974; Nos. 80 and 

1 17, 1975; Nos. 50, 143 and 205, 1976; Nos. 87 and 

20 172, 1978; No. 27, 1979; No. 24, 1980; Nos. 108 and 154, 

1981; No. 103, 1983; Nos. 47 and 123, 1984; No. 168, 1985; 

Nos. 4 1. 48, 52 and 1 54, 1 986; No. 1 38, 1 987; Nos. 73. 97. 

105 and 107, 1989; Nos. 20, 35 and 135, 1990; Nos. 4. 5. 

100 and 2 16. 1991; Nos. 80. 98 and 224, 1992: Nos. 17. 18. 

25 57 and 82, 1993; Nos. 138 and 181, 1994; Nos. 5 and 169. 

1995 

It is both difficult and impractical to store the complete amendment history of 
every word and phrase within section 6. Trying to track all changes on such a detailed 
level leads to unmanageable complexity. 
30 Largely, the split between historical and present information has come about 

because of the publishing and information industry's own development, and not because 
such is the desired or best way to manage information. Thus, a need clearly exists for an 
electronic publishing system that can overcome one or more of the disadvantages of 
conventional techniques and systems. 

35 
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International Publication No. WO 98/34179 (PCT/AU98/00050), corresponding to 
US Patent Application No. 09/108999, is incorporated herein by cross reference and 
discloses an electronic publishing system that provides a sparse multidimensional matrix 
5 of data using a set of flat file records. In particular, the computer-implemented system 
publishes an electronic publication using text-based data. Predefined portions of the text- 
based data are stored and used for the publication. At least one of the predefined portions 
is modified, and the modified version is stored as well. The predefined portion is typically 
a block of text, greater in size than a single word, but less than an entire document. Thus, 

10 for example, in the case of legislation, the predefined portion may be a section of the Act. 
Each predefined portion and the modified portion(s) are marked up with one or more links 
using a markup language, preferably SGML or XML. The system also has attributes, each 
being a point on an axis of a multidimensional space for organising the predefined 
portions and the modified portion(s) of the text-based data. This system is simply referred 

15 to as the Multi Access Layer Technology or "MALT" system hereinafter. 

Existing methods of navigating electronic publications have been derived from 
traditional methods used to navigate printed publications. Typical of these methods is the 
use of a bookmark, which is merely an indicator which identifies a page or section of 
interest. Bookmarks are typically limited in the information provided to users. 

20 Bookmarks follow a single axis, perhaps indicating the current page, chapter and title of 
the publication. However, bookmarks do not necessarily provide the user with adequate 
context pertaining to how the user arrived at the current page. If a user knows the exact 
publication desired and then navigates through the same publication, a bookmark is 
probably adequate for the user's needs. In the event that the user has conducted a number 

25 of searches and trawled through various versions of different documents to arrive at the 
current page of a publication, it is impossible for a bookmark to capture all the relevant 
information and provide the user with an adequate reading context. The book metaphor 
fails to address the abilities and complexities of electronic publications. 

Existing methods of navigating compact disc based publications and Internet sites 

30 are typically ill-suited to displaying the complex data provided by MALT. Known web 
solutions, for example, typically handle two axes, sequential and hierarchical, using either 
embedded links such as Previous, Next and Contents, or expandable content frames, as 
provided in Windows Explorer. Further axes may be handled by incorporating embedded 
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links in the body of the text. Such embedded links are point to point, and provide limited 
navigational value to the user. 

Object databases are capable of providing the required functionality, but search 
queries employed by these databases are too complicated for untrained users, both in terms 
5 of the complexity and amount of information required. 

Thus, a need clearly exists for a detailed context to be provided to users of 
electronic publishing, overcoming one or more disadvantages of existing systems. 

Summary 

10 In accordance with a first aspect of the invention, there is provided a system for 

publishing electronic information, comprising: 

a plurality of predefined portions of data with each predefined portion being 
encoded with at least one linking means, and, for each predefined portion, the each 
predefined portion is stored and, where such predefined portion has been modified, each 
15 such modified predefined portion is stored; and 

a plurality of attributes, each attribute being a point on an axis of a 
multidimensional space for organising the data. 

In accordance with a second aspect of the invention, there is provided a recording 
medium for publishing electronic information, comprising: 
20 a plurality of predefined portions of data with each predefined portion being 

encoded with at least one linking means, and, for each predefirmed portion, the each 
predefined portion is stored and, where such predefined portion has been modified, each 
such modified predefined portion is stored; and 

a plurality of attributes, each attribute being a point on an axis of a 
25 multidimensional space for organising the data. 

In accordance with a third aspect of the invention, there is provided a method for 
publishing electronic information, comprising: 

providing a plurality of predefined portions of data with each predefined portion 
being encoded with at least one linking means, and, for each predefined portion, the each 
30 predefined portion is stored and, where such predefined portion has been modified, each 
such modified predefined portion is stored; and 

providing a plurality of attributes, each attribute being a point on an axis of a 
multidimensional space for organising the data. 
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According to a first aspect of the invention, there is provided a method of 
navigating in a multidimensional space having three or more dimensions. The method 
includes the steps of: 

displaying in a first display region a selected predefined portion of an electronic 
5 publication formed from predefined portions of text-based data encoded using a markup 
language, each predefined portion having at least one attribute being a coordinate of an 
axis of the multidimensional space, wherein logical connections among the predefined 
portions, and any logical connections between the predefined portions and predefined 
portions of any further electronic publication data in the multidimensional space, 
10 correspond to one or more axes of the multidimensional space; 

displaying a point on a primary axis of the multidimensional space dependent upon 
an attribute of the displayed predefined portion; 

displaying a second point on a second, viewing axis orthogonal to the first axis, the 
second point being derived from the first point dependent upon a logical connection 
15 between the displayed predefined portion and a predefined portion associated with the 
second point; and 

displaying information regarding the second point of the second axis in a second 
display region, the first and second points being displayed in two display regions. 

According to a second aspect of the invention, there is provided a method of 
20 navigating in a multidimensional space having three or more dimensions, the 

multidimensional space containing an electronic publication formed from predefined 
portions of text-based data encoded using a markup language. The method includes the 
steps of: 

providing a view comprising at least two anchor sets; 
25 displaying at least one base point and at least a first axis depending from the base 

point; 

displaying at least one of a further point and an axis derived from the base point; 

navigating a multidimensional space formed by the points and axes; 

returning to the base point when required; and 
30 adjusting the view so a current view point becomes a new base point. 

According to a third aspect of the invention, there is provided an apparatus for 
navigating in a multidimensional space having three or more dimensions. The apparatus 
includes: 
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a device for displaying in a first display region a selected predefined portion of an 
electronic publication formed from predefined portions of text-based data encoded using a 
markup language, each predefined portion having at least one attribute being a coordinate 
of an axis of the multidimensional space, wherein logical connections among the 
5 predefined portions, and any logical connections between the predefined portions and 
predefined portions of any further electronic publication data in the multidimensional 
space, correspond to one or more axes of the multidimensional space; 

a device for displaying a point on a selected axis of the multidimensional space 
dependent upon an attribute of the displayed predefined portion; 
10 a device for displaying a second point on a second, viewing axis orthogonal to the 

selected axis, the second point being derived from the first axis at the first point dependent 
upon a logical connection between the displayed predefined portion and a predefined 
portion associated with the second point; and 

a device for displaying information regarding the second point of the second axis 
15 in a second display region, the first and second points being displayed in two display 
regions. 

According to a fourth aspect of the invention, there is provided an apparatus for 
navigating in a multidimensional space having three or more dimensions, the 
multidimensional space containing an electronic publication formed from predefined 
20 portions of text-based data encoded using a markup language. The apparatus includes: 
a device for providing a view comprising at least two anchor sets; 
a device for displaying at least one base point and at least a first axis depending 
from said base point; 

a device for displaying at least one of a further point and an axis derived from the 
25 base point; 

a device for navigating a multidimensional space formed by the points and axes; 
a device for returning to the base point when required; and 

a device for adjusting the view so a current view point becomes a new base point. 

According to a fifth aspect of the invention, there is provided a computer program 
30 product having a computer readable medium having a computer program recorded therein 
for navigating in a multidimensional space having three or more dimensions. The 
computer program product includes: 

a computer program code module for displaying in a first display region a selected 
predefined portion of an electronic publication formed from predefined portions of text- 
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based data encoded using a markup language, each predefined portion having at least one 
attribute being a coordinate of an axis of the multidimensional space, wherein logical 
connections among the predefined portions, and any logical connections between the 
predefined portions and predefined portions of any further electronic publication data in 
5 the multidimensional space, correspond to one or more axes of the multidimensional 
space; 

a computer program code module for displaying a point on a primary axis of the 
multidimensional space dependent upon an attribute of the displayed predefined portion; 
a computer program module for displaying a second point on a second, viewing 
10 axis orthogonal to the first axis, the second point being derived from the first point 
dependent upon a logical connection between the displayed predefined portion and a 
predefined portion associated with the second point; and 

a computer program code module for displaying information regarding the second 
point of the second axis in a second display region, the first and second points being 
15 displayed in two display regions. 

According to a sixth aspect of the invention, there is provided a computer program 
product having a computer readable medium having a computer program recorded therein 
for navigating in a multidimensional space having three or more dimensions, the 
multidimensional space containing an electronic publication formed from predefined 
20 portions of text-based data encoded using a markup language. The computer program 
product includes: 

a computer program code module for providing a view comprising at least two 
anchor sets; 

a computer program code module for displaying at least one base point and at least 
25 a first axis depending from said base point; 

a computer program code module for displaying other points, axes or both derived 
from said base point; 

a computer program code module for navigating a multidimensional space formed 
by said points and axes; 
30 a computer program code module for returning to said base point when required; 

and 

a computer program code module for adjusting the view so a current view point 
becomes a new base point. 
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According to a seventh aspect of the invention, there is provided a method of 
publishing an electronic publication formed from predefined portions of text-based data 
encoded using a markup language. The method includes the steps of: 

storing predefined portions in terminal nodes; and 
5 providing one or more higher level nodes for organising the terminal nodes to 

correspond with a hierarchical structure embodied in the electronic publication, wherein 
each higher level node consists of the identity of a parent node, a position indicator for the 
higher level node, and an identifier; 

wherein one of the higher level nodes has a null parent identity, and the position 
10 indicator indicates a position of the higher level node relative to a sibling node. 

According to an eighth aspect of the invention, there is provided an apparatus for 
publishing an electronic publication formed from predefined portions of text-based data 
encoded using a markup language. The apparatus includes: 

a device for storing predefined portions in terminal nodes; and 
15 a device for providing one or more higher level nodes for organising the terminal 

nodes to correspond with a hierarchical structure embodied in the electronic publication, 
wherein each higher level node consists of the identity of a parent node, a position 
indicator for the higher level node, and an identifier; 

wherein one of the higher level nodes has a null parent identity, and the position 
20 indicator indicates a position of the higher level node relative to a sibling node. 

According to a ninth aspect of the invention, there is provided a computer program 
product having a computer readable medium having a computer program recorded therein 
for publishing an electronic publication formed from predefined portions of text-based 
data encoded using a markup language. The computer program product includes: 
25 a computer program code module for storing predefined portions in terminal 

nodes; and 

a computer program code module for providing one or more higher level nodes for 
organising the terminal nodes to correspond with a hierarchical structure embodied in the 
electronic publication, wherein each higher level node consists of the identity of a parent 
30 node, a position indicator for said higher level node, and an identifier; 

wherein one of the higher level nodes has a null parent identity, and the position 
indicator indicates a position of the higher level node relative to a sibling node. 
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According to a tenth aspect of the invention, there is provided a method of 
publishing an electronic publication formed from predefined portions of text-based data 
encoded using a markup language. The method includes the steps of: 

storing predefined portions in terminal nodes; and 

providing one or more higher level nodes for organising the terminal nodes to 
correspond with a hierarchical structure embodied in the electronic publication, wherein 
each higher level node consists of the identity of a parent node, a position indicator for the 
higher level node, and an identifier, the predefined portion includes text associated with a 
commentary, and a scope including a start date, an end date and an update date, the update 
date being later than the start date and earlier than the end date; 

further wherein one of the higher level nodes has a null parent identity, and the 
position indicator indicates a position of the higher level node relative to a sibling node. 

Other aspects of the invention are also disclosed. 

Brief Description of the Drawings 

A small number of embodiments of the invention are described with reference to 
the drawings, in which: 

Fig. 1 illustrates a grid of a multidimensional space according to the first 
embodiment: 

Fig. 2 illustrates the effect of the various axes; 

Fig. 3 illustrates the mapping of various axis intersection points, or nodes, that is 
used to organize, present, and find information (present and past) according to the first 
embodiment; 

Fig. 4 illustrates the application of legal information to mapped nodes according to 
the first embodiment; 

Fig. 5 is a block diagram illustrating a general purpose computer that can be used 
to implement the electronic publishing system according to the first embodiment; 

Fig. 6 is a flow diagram illustrating the method of electronic publishing according 
to the first embodiment; and 

Figs. 7 to 17 are screen shots illustrating operation of the first embodiment as a 
software application executing on a general purpose computer. 

One or more embodiments of the present invention are described hereinafter with 
reference to the drawings, in which: 
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Fig. 1 Fig. 18 is a screen shot of a Normal axis view of a MALT publication (with 
a search mode enabled) in accordance with an embodiment of the present invention; 

Fig. 2 Fig. 19 is a screen shot of a Versions axis view of a MALT publication in 
accordance with an embodiment of the present invention; 
5 Fig. 3 Fig. 20 is a screen shot of a Source axis view of a MALT publication in 

accordance with an embodiment of the present invention; 

Fig. A Fig. 21 is a block diagram representation of higher level scoping in 
accordance with an embodiment of the present invention; 

Figs. 5A, 5B and 5C Figs. 22A. 22B and 22C are screen shots illustrating a 
10 commentary in accordance with a further embodiment of the invention; and 

Fig. 6 Fig. 23 is a computer program product block diagram. 

Detailed Description 

The present invention is directed towards a system of electronic publishing that can 
15 overcome the disadvantages of conventional information publishing, both in print and 

electronic form. The present invention reduces, if not eliminates, end user problems with 
conventional information publishing including: 

(1) the connectivity between related pieces of information; 

(2) analysis of the type and subject of information; and 

20 (3) finding information appropriate to the point in time with which they are 

concerned. 

Overview of Embodiments 

The embodiments of the invention provide an entirely new way of delivering, 
25 storing and publishing information. The embodiments allow publishers to add an arbitrary 
number of logical connections to a set of data, and even permit the publisher to display the 
precise evolution of that data set over time. This can be done without getting bogged 
down in the complexity of the logical connections and without limit as to storage space. 

Frequently, people desire to have more "information" available. However, with the 
30 advent of the Internet and new technology, many people suffer from information overload. 
The embodiments of the invention provide an easy and effective way to navigate large 
complex volumes of information. 

Conventionally, information may only contain very rudimentary (i.e., haphazard 
hyperlinks) or non existent logical connections. Thus, conventional techniques of 
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investigating how a set of data has evolved and changed over time can only be done for 

small data sets and are very expensive. 

However, with the embodiments of the invention, it is possible to list all logical 

connections within a data set no matter how complex those connections may be. The 
5 embodiments of the invention and the principles of those embodiments described 

hereinafter can be applied to many different types of information such as medical, 

scientific, pharmaceutical, etc. For ease of description, however, the embodiments are set 

forth in relation to legal information. 

Conventionally, legislation is often purchased in two ways: (1) The individual 
10 Numbered Acts and Regulations that give each piece of legislation as it is passed; and (2) 

Consolidated legislation that provides the latest consolidated version. 

In the embodiments of the invention, legislation is stored using every version of 

each Act or Regulation. The end user can search every version of any section, schedule, 

or provision. For example, the required version of a section is immediately available as is 
15 the opportunity to view every preceeding and subsequent version of the same section. 

Also, links are available to any relevant amending legislation commencing that change, as 

well as the one that repealed it. Relevant Application, Saving or Transitional Provisions 

can also be easily accessed. 

In this manner, it is possible to come to a full understanding of the legislation just 
20 by looking at the data provided through the embodiments of the invention. In contrast, 

using conventional techniques, it would have been impossible or very hard, expensive and 

time consuming to do so. 

Using conventional means, a person wishing to view a particular section of a 

particular Act (e.g., the Income Tax Assessment Act) as of a particular date (e.g.. 30th 
25 June 1996), a significant amount of work would be required to do so. The end user would 

need to track all Amendments since the last reprint of the legislation, which may take a 

long time and involve referring to many volumes. This may even possibly involve using 

scissors and paste to actually cut and replace words. Even to figure out which Acts 

amended a particular section and to trace those commencement dates can be difficult, time 
30 consuming and trying. However, a piece of research that may have taken an experienced 

researcher days or even weeks can be accomplished in minutes using the embodiments of 

the invention. 

The ability to move through information in time is outlined above. The 
embodiments of the invention also give additional flexibility and SCOPE to the end user. 
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Further dimensions and interconnections may include: type, jurisdiction, subject, depth. 
Some examples are: 

1. Doing research on the subject evidence at depth confession for types 
Acts and Case for time period 12 months. 
5 2. Doing research on type cases within jurisdictions NSW and Queensland 

subject murder and depth statutes dealing with subject. 
The ability to associate the relevance and interconnection contained within the 
information is highly advantageous to the end user. 

A key aspect of the embodiments of the invention in successfully providing a 

10 multi-dimensional repository of information has been in deciding the "optimum storage 

unit". In the past publishers have chosen to either store new versions of the entire Act (too 
big) or new versions of each and every change, in a method similar to red lining (too 
complex). The first aspect of the invention was to analysis the data and choose to store 
every version of every section or provision level of legislation. 

15 Structured Generalised Markup Language (SGML) is a recognised way to mark up 

data. SGML allows logical structure to be added to a document (unlike HTML and word 
processors which only allow the addition of visual content). SGML alone is not enough to 
deal with text-based data that contains a highly complex logical structure. The complexity 
increases exponentially until the complexity cannot be managed any more. Large legal 

20 publishers have stored their data in SGML, but those legal publishers that are successful in 
dealing with their SGML-based data have purposely kept their markup as simple as 
possible. When such publishers have tried to encode a complex structure on text-based 
data their costs of creating the data set and maintaining the data set simply went through 
the roof, and it became impossible to maintain the integrity of the data set. 

25 In contrast, the embodiments of the invention allow SGML data to be encoded 

with a much more complex structure whilst remaining manageable. Alternatively, 
Extensible Markup Language (XML) may be used. For example, with SGML it is 
possible to encode all 7 1 versions of Section 6 of the Australian Federal Income Tax 
Assessment Act in a single file (that Act has about 6,000 sections) but this would be 

30 utterly unmanageable when applied to the 6,000 other sections of the Income Tax 

Assessment Act. It becomes even more unmanageable if anybody would try to use the 
above method on all the sections within all other Acts and Regulations of the 
Commonwealth. A significant problem with using SGML, even well executed SGML, is 
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that it is possible to quickly get bogged down in unmanageable levels of complexity. The 
embodiments of the invention have overcome these problems. 

Another key aspect of the invention is the use of database technologies in the 
management of the SGML encoded techniques. Database technology provides a large 
5 number of ready tools to deal with complex structured data. The embodiments combine 
these technologies (SGML, XML and database technologies) in an advantageous manner. 

In the past, traditional publishers have been limited by the size and speed of 
available storage systems. Only a limited amount can be reproduced in paper and until 
recently hard disk costs prohibited the storing of multiple gigabytes of data, for both 
10 publishers and clients alike. 

The embodiments of the invention have the ability to look at situations from a new 
and up-to-date view point and therefore come up with innovative conclusions that can be 
radically different to processes employed in the past. 

Thus, the embodiments of the invention provide a new computer publishing system 
15 that changes the availability of electronic information from being merely "speeded up 
paper" to being electronic information taking advantage of new electronic media by 
providing users with enhanced functionality of data retrieval and manipulation. The 
information included in the electronic format is of a publishable standard, meets cost 
constraints and is able to be accessed under any combination of dimensions from the 
20 multi-dimensional space (Acts, cases, time, jurisdiction, subject). The publishing system 
facilitates continual updates to the data contained in the databases, without any adverse 
effects on the operating capabilities that make the publishing system unique. Due to the 
extra functionality, the publishing system is also designed in such a way that it can still be 
made available in as many different electronic media as possible, and all search functions 
25 are able to operate in a time-efficient manner. 

The embodiments of the invention organize, process and present information in a 
way that is significantly different than conventional structures, processes and presentation. 
They provide an information storage and publishing system, and in particular, an 
information storage and publishing system that stores and manages large and 
30 comprehensive amounts of information (eg, legal information). 

Publication data, being preferably legal information, is encoded using Standard 
Generalized Markup Language (SGML) or Extensible Markup Language (XML) which 
adds codes to the publication data and provides functionality to the data. The publication 
data is processed as a plurality of predefined portions, which in the case of legislation is 
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preferably at the section, schedule level, or provision level. A hierarchy of divisions of the 
legislation may be implemented. For each of the predefined portions, the system stores a 
copy of the predefined portion and a modified predefined portion in the first database 
whenever it is changed. A second (relational) database is preferably provided that 
5 comprises plural attributes for managing the information of the first database, with each 
attribute being a point on an axis of a multidimensional space for organising the data for 
publication. Alternatively, a single repository of information may be practised as 
described with reference to the second embodiment. 

The system enables the first database to be searched for one of the predefined 

10 portions of the publication data using attributes of the second database by following one or 
more pathways through the multidimensional space. The plurality of attributes are 
connected to by the plurality of links. Once the desired predefined portion is located, the 
predefined portions can be retrieved using the attributes to define a point in the 
multidimensional space. 

15 Preferably, the system implements, inter alia, time-based legislation in which 

sections of legislation that have been amended are not discarded and replaced with the 
current provision only as of the publication date. Instead, each version of an amended 
section is retained in the first database. Thus, the systems according to the embodiments 
of the invention are particularly advantageous in that legal information is published so that 

20 a user can obtain such sections or provisions at a particular time point. 

The embodiments advantageously divide information into "suitably" small pieces 
(or blocks) of text, each of which is a predefined portion of data, and add to each piece of 
text, either expressly or implicitly, a number of attributes (characteristics or descriptors). 
The suitability as to size of text pieces is determined by an analysis of the information and 

25 its naturally occurring structure based on knowledge of how the information is used and 
consumed by the end user. 

This makes it possible to locate each piece or block of text at a particular point in a 
"multidimensional space 1 ' using as coordinates the attributes added to the piece or block of 
text. Multidimensional space refers to an area not having boundaries and that is capable 

30 of, or involves, more than three dimensions. 

Fig. 1 illustrates a multi-dimensional space 100 as used in embodiments of the 
invention. The multidimensional space is represented by a layered grid. The diagram 
represents axes or pathways as vertical and horizontal lines; in reality (in the case of more 
than two dimensions), thev are at all angles and inclines. 
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Referring to Fig. 2, the ability to locate (assign) or map each node 102 (or key 
intersection point of the various axes or pathways) is a significant functional aspect of the 
embodiments of the invention. This mapping is explained further hereinafter. With such 
coordinates 102 known (located or mapped), it is possible to move easily between points 
5 in the multidimensional space 100. 

The effect of mapping nodes as shown in Fig. 3 is that a course 320 through the 
information represented in the three-dimensional space 100 can be easily plotted. The 
user begins the course 320 at node 302 and progresses vertically downward to the fourth 
node 304. Further, the plotted course 320 is flexible to the extent of the relationships a 
10 user chooses to follow or seek out. 

First Embodiment 

A first embodiment of the invention provides information management in the 
multidimensional space and allows movement along different axes or "pathways": 
15 location of the information (its address); 

type of information (its genesis); 

jurisdiction (its class); 

subject (its content description); 

depth (extent of content); and 
20 time (the point in time at which the information is viewed). 

In the first embodiment, coding of information or data for publication is based on 
SGML or XML and one or more specifically developed Document Type Definitions 
(DTD), which preferably is specifically designed for legal information. Alternatively, in 
the case of XML, a Style Sheet Mechanism (SSM) may be used. This coding can then be 
25 related back to information retained in a specifically developed database that enables the 
code information to be managed and updated. For a detailed description of this aspect of 
the invention, reference is made to Appendix C. The DTDs according to the first 
embodiment are set forth in detail in Appendix B. A DTD is used to define the structure 
of publication data, preferably being legislation, down to a comprehensive level. This is 
30 done by using information coded in conjunction with any one of a number of off-the-shelf, 
free- text retrieval software packages (eg. Folio Views or Dvnatext ) to deliver the 
information to the end user. 

A DTD describes the markup for the SGML publication data, or "repository", 
which may contain legislation, case law, journal articles and other types of material that 
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are stored in computer files. The files contain publication data in text form and the 
markup, which is extra information about the text included with the text. An example of a 
markup is '<BD +>' which indicates that "the data from this point on is bold". A further 
example is 

5 '<SECTION ID = "CWACT- 19950104-SEC-l" LBL = "l'V. This markup 

indicates that: the data from this point on is part of a section of legislation; the section has 
an identifier of CWACT- 19950104-SEC-l; and the section has a label of "1". 

There are a number of different ways to add markup to data. The first embodiment 
adds markup to data using SGML. Alternatively, XML may be used. Still further, in the 

10 case of XML being used, an SSM may be used. Even within SGML, there are many ways 
to add markup to text. Each particular way of adding markup within SGML is described 
by using a DTD. In the first embodiment, the data for publication is marked up using a 
number of different DTDs. In particular, the DTDs are used to mark up the logical 
structure of the legislation, case law or journal articles. Significant amounts of 

15 information about the data for publication is stored in the markup. For example, the 

markup ^SECTION ID= "CWACT- 19950104-SEC-l" LBL= , T'> t provides the following 
information: the data is a piece of Commonwealth of Australia legislation (indicated by 
'CW at the beginning of the string): the section is part of an Act ('ACT' after 'CW') and not 
a regulation; the act is Act No. 104 of 1995 ('19950104' in the middle of the string), the 

20 data is a Section ('SEC) within the Act; and it is Section 1 (T at the end). 

The preparation of such DTDs necessitates that the author has a sound knowledge 
of the data that will be marked up using the DTD. It is especially important that the 
underlying structure of the data to be marked up using the DTD be understood. The 
process of becoming acquainted with the structure of the data to be marked up is referred 

25 to hereinafter as "content analysis". 

In particular, the section-level or schedule-level portion of legislation is used in the 
first embodiment. That is. the section-level portion is preferably the predefined portion of 
the publication data, which is the smallest piece of information to be tracked. This is 
unlike conventional publishing systems. For example, with reference to Table 1, the first 

30 embodiment stores every version of Section 6. In this manner, complexity (tracking every 
word) is reduced by increasing storage. However, unlike example (I) of conventional 
publishing systems, the first embodiment does not lose any pertinent information: 
a) every version of each Act or Regulation is stored; 
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b) the end user can search every version of any section or schedule at the same 
time; 

c) it is easy to know which particular section or schedule has changed, to track 
how that particular section or schedule has changed, and to find the relevant 

5 section of the Amending Act or Regulation that affected the section or 

schedule; 

d) if multiple changes have occurred on a particular section or schedule, every 
version of the section or schedule can be seen; 

e) issues like commencement of the latest version of a particular section or 

10 schedule and so-called "Application, Saving or Transitional Provisions" can 

easily be recreated; 

f) it is possible to come to a full understanding of the legislation just by looking at 
the data provided through the first embodiment. 

A further advantage of tracking every version of each section or schedule is that it 
15 is possible to store some of the information, not in the markup, but in a database, as noted 

hereinbefore. This simplifies the updating process. 

While SGML is a powerful way of storing information, it is not a retrieval 

medium. Therefore, the stored information needs to be converted into a format that the 

end user of the information can access. The first embodiment uses an electronic format 
20 for retrieval. For this electronic retrieval, a software application called 'high-end text 

retrieval software* is used. Examples of high-end, text-retrieval software applications 

include Folio Views and Dvnatext. In the first embodiment. Folio Views is used. 

Folio Views has its own proprietary markup language, which is not part of the 

SGML family. A complete guide to the Folio Views markup language is provided in the 
25 text Folio Views Infobase Production Kit Utilities Manual, Version 3.1. Provo, Utah: 

Folio Corporation (1 June 1994). Storing the data for publication in SGML allows other 

retrieval software applications besides Folio Views to be used. 

In the first embodiment, a process is implemented to convert the SGML marked-up 

data into the format used by the retrieval software application. The example given for 
30 Folio Views hereinafter is but one example of the process involved. The conversion 

program basically maps the SGML markup to Folio Views markup. For example, for the 

SGML markup '<SECTION ID= "CWACT- 19950104-SEC-l" LBL= "!">'. the 

conversion process marks all IP's substantively unchanged as Jump Destinations (JD's): 

'<JD: = "CWACT- 19950104-SEC-rV. 
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A Keying Guide for Australian Legislation Documents with instructions for the 
conversion process to Folio Views added is provided in Appendix D. 

Movement through legal information can be as follows (the flexibility and scope is 
largely up to the end user): 

(1) doing research on the subject of fences and boundaries at the depth fences that 
are hedges looking for types Acts and Regulations in jurisdictions NSW and 
Victoria for the time period last 20 years; 

(2) doing research on the subject evidence at depth confession for types Acts and 
cases for time period last 12 months; or 

(3) doing research on type cases with jurisdictions NSW and Queensland, subject 
murder and depth statutes dealing with subject. 

The application of legal information to mapped nodes is shown in Fig. 4. 
However, this is only one of numerous possible applications. Information from medicaL 
technical and scientific areas are all open to the application of this invention. This 
diagram substitutes the technical terminology of Figure 3 with legal terms to show the way 
information appears according to the first embodiment. Further, Fig. 4 provides an 
example of how legal information is navigated by an end user. The user may be seeking 
information on the following matters: 

(1) Does NSW legislation on fences presently cover hedge rows between the 
boundary of a private property and a public road? 

(2) If not, have such hedge rows ever come under NSW legislation? 

(3) Are there any cases under current law or previous law? 

(4) How have the cases been interpreted? 

Some general assumptions are made about legal information for the purposes of 
this example. Broadly, legal information has two main primary sources: statute law 
(including subordinate legislation), and case law. There is also secondary information 
such as commentary which can be added to aid interpretation. Each of these sources is 
interconnected and relevant to the other in terms of both past and present information. 
This may also apply to future information in terms of bills or other forms of uncommenced 
legislation. It is the association of this relevance and interconnection that is advantageous 
to the end user. 

In Fig. 4, the X-, Y-, and Z-axes indicate time (Time), the legislative provision 
(location), and type (eg, legislation=L, cases=C, and journal articles=J). To simplify the 
diagram, only three axes are illustrated, however, other axes may be included dependent 
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upon the number of dimensions of the space. In the first embodiment, the 
multidimensional space also includes another three axes: iurisdiction=U. subiect=V. and 
depth=W. Thus, the space according to the first embodiment has six dimensions. In the 
six-dimensional case, it is possible to move along each axis and at the points of 
5 intersection change direction, as well as find and/or follow new or additional information. 

The end user begins at legislation (L) along the Z-axis, where the Fences 10 and 
Boundaries Act is located and then selects Section 1 of legislation (indicated by L 
allowing the Z-axis) at node 402. as of 1 January 1996. The user then follows a path in the 
legislation through nodes 404, 406 and 408 for Sections 2, 3 and 4. respectively, as of that 

10 same date (ie. the Y-axis), to find a definition of the term "fences". Node 408 contains 

Section 4 at 1 January 1996 which contains the current definition of "fences". This would 
provide information in response to above query (1). 

The user then selects Section 4 of the legislation as of 1 January 1995, which in 
this case is an earlier version of the section prior to amendment, by moving to node 410 

15 (along the X-axis). This provides information about the prior law for above query (2). 
The user can then move to other information on Section 4 as of 1 January 1995 by going 
to nodes 412 and 414 for case and journal article information, respectively, along the Z- 
axis. For example, a case on the earlier Section 4 might be identified at node 412 and 
articles on interpretation of Section 4 at node 414. The foregoing is only one possible 

20 route through the multidimensional space of information. Other more complicated and 
interrelated pathways involving axes U. V and W are possible. For example, the user can 
move to axis U (jurisdiction) and compare the definition in Section 4 of New South Wales 
with that in another jurisdiction (eg. Victoria). 

Fig. 6 is a flow diagram illustrating the method of electronic publishing according 

25 to the first embodiment. A data source 602, preferably for legal information, is provided. 
In steps 604 and 606, base data and new data are input from the data source 602, 
respectively, and in step 608 the data is captured. The DTDs 610 are input to step 612. 
The DTDs 610 include Act.DTD, Acts.DTD, Reg.DTD. Regs.DTD. and Common.ELT, 
which are shown in detail in Appendix B. In step 612, the DTDs 610 are applied to the 

30 captured data from step 608. In step 614, the data is coded in SGML, including the Time 
Base Code. In step 616, the data is consolidated. As indicated in Fig. 6. steps/items 602 
to 616 comprise the (first) data conversion stage. 

A data management database 620 is provided to step 618. The database is based 
on a master table and a textblock table (see Appendix C for further detail). The output of 
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step 616 is also provided to step 618. In step 618. the data is consolidated; the data is 
stored as multiple versions, if applicable, and uses the predefined portions of data Tie, 
textblocks). In step 622. a filter program(s) is applied to the consolidated data to convert 
the data from SGML to the relevant format for the retrieval software application, including 
5 Folio Views. DvnaText. Topic. HTML, and the like. Steps/item 618 to 622 comprise the 
(second) data management stage. 

The filtered data output by step 622 can then be provided to step 624. In step 624. 
the filter consolidated data is imported to the text retrieval software. In step 626. the data 
is provided to the delivery medium, which may include CD- ROM, DVD, magnetic tape. 

10 electronic online services, and other media. The output of this is the end user product 628. 
Steps/item 624 to 628 comprise the (third) product manufacture stage. 

The first embodiment is preferably practiced using a conventional general- purpose 
computer, such as the one shown in Fig. 5. wherein processes for providing and managing 
the information are carried out using software executing on the computer. In particular. 

15 the legislation database, the database and the DTD(s) may be stored after a filtering 

process on a CD-ROM used by the computer system, and the computer system is operated 
using Folio View. The computer system 500 includes a computer 502, a video display 
516. and input devices 518. A number of output devices, including line printers, laser 
printers, plotters, and other reproduction devices, can be connected to the computer 502. 

20 Further, the computer system 500 can be connected to one or more other computers using 
an appropriate communication channel such as a modem communications path, a 
computer network, or the like. 

The computer 502 consists of a central processing unit 504 (simply, processor 
hereinafter), an input/output interface 508, a video interface 510, a memory 506 which can 

25 include random access memory (RAM) and read-only memory (ROM), and one or more 
storage devices generally represented by a block 512 in Fig. 5. The storage device(s) 512 
can consist of one or more of the following: a floppy disc, a hard disc drive, a magneto- 
optical disc drive. CD-ROM or any other of a number of non-volatile storage devices well 
known to those skilled in the art. Each of the components 504 to 512 is typically 

30 connected to one or more of the other devices via a bus 514 that in turn can consist of data, 
address, and control buses. 

The video interface 510 is connected to the video display 516 and provides video 
signals from the computer 502 for display on the video display 516. User input to operate 
the computer 502 can be provided by one or more input devices. For example, a operator 
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can use the keyboard 518 and/or a pointing device such as the mouse to provide input to 
time computer 502. Exemplary computers on which the embodiment can be practiced 
include Macintosh personal computers. Sun SparcStations, and IBM-PC/ATs and 
compatibles. 

5 In an alternate embodiment of the invention, the computer system 500 can be 

connected in a networked environment by means of an appropriate communications 
channel. For example, a local area network could be accessed by means of an appropriate 
network adaptor (not shown) connected to the computer, or the Internet or an Intranet 
could be accessed by means of a modem connected to the I/O interface or an ISDN card 

10 connected to the computer 502 by the bus 514. In such a networked configuration, the 

electronic publishing system can be implemented partially on the user's computer 500 and 
a remote computer (not shown) coupled over the network. The legislation database, the 
database and the DTD(s) can be implemented on the remote computer and the computer 
system 500 can be operated using Folio View. 

15 The operation of the first embodiment is described with reference to the screen 

shots shown in Figs. 7 to 17. All screen shots are derived from the first embodiment 
which uses Folio Views as the retrieval software. Broadly, Figs. 7 to 15 are screen shots 
illustrating navigation or movement around the information. Figs. 16 and 17 are screen 
shots that show search capacities. 

20 Fig. 7 shows the opening screen 700, which the end user sees when the program is 

started. The interface is a standard windows interface featuring drop menus that provide 
access to all functions. The functions include basic searching and customised search 
templates such as the ones shown in Figs. 16 and 17 that allow users to exploit time-based 
and multidimensional searching. 

25 The title screen 702 is presented when the process is commenced and is the first 

screen. A customisable toolbar 704 is provided for searching functions. Also, drop menus 
706 are provided above the toolbar 704. In the lower portion of the screen 700 contains a 
status bar 708 showing information relevant to searching. The Start and Main menu 
buttons 710 in Fig. 7 are both navigational tools. The Start button takes a new user to 

30 information providing help on how to use the invention. The Main Menu button takes the 
end user to the menu shown in the second screen shot of Fig. 8. 

Fig. 8 shows a main selection menu 800. At this menu 800, the user can see the 
currency of the total information. The user is also able to make broad choices as to the 
type of information that the person might like to see. All items preceded by bullet points 
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in the menu are jump links 802 which lead the user to further menus for the items selected. 
The jump links 802 also provide a uniform or consistent form of movement. Thus 1 if 
searching the Social Security Act, selecting the first jump link "Find an Act' 1 takes the user 
to the next screen which would be the "Act Name Menu". 
5 Fig. 9 shows the "Act Name Menu" screen 900. In this menu 900, all letter buttons 

are links 904 to Acts beginning with the letter selected. That is, the jump links 904 allow 
access to sub-menus for Acts with the corresponding selected letter. If "S" is clicked, this 
leads to the "Acts beginning with S" menu (see Fig. 10) where an entry linked to the most 
current version of the Social Security Act 1991 appears. A similar menu may be provided 
10 for Regulations. Further, locational information 902 is provided in the upper portion of 
the screen 900. 

Fig. 10 illustrates acts beginning with "S". as selected in the screen 900 of Fig. 9. 
By selecting jump link 1002. the Social Security Act can be accessed. Likewise, other 
acts in this screen 1000 may be accessed using the respective jump link (e.g. Safety. 

15 Rehabilitation and Compensation Act. 

Assuming the appropriate jump link 1002 is selected in Fig. 10. Fig. 1 1 shows how 
the beginning of the Social Security Act appears in screen 1 100. and the buttons that link 
the user to the provisions of the Act. This is the start of the most current version of the 
Social Security Act preferably. From this screen, provisions of the Act can be accessed. 

20 By accessing the Table of Provisions box, the Table of Provisions menu can be accessed. 
Fig. 12 shows the Table of Provisions screen 1200. and illustrates how a specific 
provision, say Section 4, can be accessed again using links 1206. Different sections of the 
Act (e.g. ss 3. 4 and 6A) may be accessed as well using corresponding jump links. Again, 
location information 1202 is provided in the upper portion of the screen. A return button 

25 1204 is also provided that provides access back to the beginning of the Act. 

Fig. 13 shows screen 1300 containing the Time Base Toolbar 1302, which 
preferably provides eight buttons for accessing time based information. This Toolbar 
1302 is not a feature of Folio Views, but is a designed addition added to Folio Views by 
the first embodiment. It is made possible by the way in which the publication data is 

30 coded. The Section Information button 1304 takes the user to an overview of information. 
The Previous, Next and All buttons 1306 allows the user to have access to the previous, 
next and all versions of the relevant section. The Subject. Jurisdiction and Related Info 
buttons 1308 allow the user to view and access sections dealing with a similar subject, or 
similar sections in other jurisdictions, or related information such as cases and articles on 
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or about the section. This Toolbar 1302 allows a user to cycle through previous and 
subsequent versions of sections and as shown in screens in Figs. 14 and 15 to refer to the 
text of sections amending the section. As well, the user can also call to the screen all 
versions of the section as one view for display) using the "ALL" button. 
5 Fig. 14 illustrates a screen 1400 which appears when the user selects the Section 

information button 1402 (button 1304 in Fig. 13). The resulting popup screen illustrates 
the time period or date range 1404 covered by this version of section 4. It also indicates 
the Year and Number jump link 1406 to text of the amending act which created this 
version of section 4. 

10 Fig. 15 illustrates a screen 1500 which appears when the user selects the previous 

button 1502 (not shown - it is located behind the popup screen), which corresponds to 
previous button 1306 of Fig. 13. This shows an earlier version of section 4 that the user 
can access by using the previous button 1502. The pop-up screen indicates that this 
version covers a different time span than that shown in Fig. 14. 

15 The screen shots in Figs. 7 to 15 display a step-through or navigation-based way of 

locating information. There is also the more direct approach of searching for terms using 
text retrieval. The screen shots in Figs. 16 and 17 illustrate such searching provided by the 
first embodiment. Screen 1600 shown in Fig. 16 provides a customised search template 
1602 that includes a time base option allowing a user to search for versions of a section, 

20 for example. Screen 1700 shown in Fig. 17 illustrates a customised search template 1702 
for case law which includes a time base option connecting cases to legislation at a 
particular date, for example. Again, the ability to relate such to time and then to mix and 
match types of information from different sources (jurisdictions) is a feature provided by 
the coding technique used for the data and not the Folio Views software used to deliver the 

25 data to the end user. 

Second Embodiment 

The second embodiment stores all the information in a single repository which is 
marked up in SGML or XML. The information is divided in that repository into suitable 
30 pieces or blocks of text (as described in the first embodiment) and any relevant markup 
marks up a whole suitable piece or block of text by (a) choosing suitable pieces or blocks 
of text, and (b) demanding that relevant markup belongs to a whole suitable piece or block 
of text, the following becomes possible. A relational database consisting of records 
consisting of fields can be created with one and only one record per suitable piece or block 
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of text where the actual text of each suitable piece or block of text is the content of one 
filed of the above record and where each item of the markup is assigned its own field in 
the above record. 

For example, a version of Section 6 of the Income Tax Assessment Act (ITAA) 
5 1936 may be stored as a record in the above relational database. The first field of that 
record contains the actual text of that version of Section 6. The next field identifies it as 
Section 6 of the ITAA, the next field gives the date this version came into being, the next 
field contains the section of the amending act that created this particular version, the next 
field contains the day this version became superseded, another field contains the subject(s) 
10 this version addresses, another field contains the case(s) that have addressed this version 
of section 6 and so on. Storing the data in this way allows multidimensional database 
techniques to be applied to the data. 

An XML DTD for implementing the second embodiment is set forth in Appendix 
E. It will be apparent to one skilled in the art that the second embodiment may be readily 
15 implemented in view of the foregoing description of the first embodiment, which is not 
repeated here for the purpose of brevity, and in view of the accompanying DTD set out in 
Appendix E. 

The foregoing only describes a small number of embodiments of the invention, and 
modifications and changes apparent to those skilled in the art can be made thereto without 
20 departing from the scope and spirit of the invention. For example, the embodiments of the 
invention have been described with reference to SGML. The embodiments may 
alternatively be practiced with the extensible markup language (XML) as well. Also, the 
embodiments may alternatively be practiced with a Style Sheet Mechanism (SSM) instead 
of, or in addition to, one or more DTDs. 

Overview 

A method, apparatus and computer program product for navigating in a 
multidimensional space containing an electronic publication formed from predefined 
portions of text-based data encoded using a markup language are disclosed. In the 
following description, numerous specific details are set forth. However, it will be apparent 
to those skilled in the art in view of this disclosure that changes may be made without 
departing from the scope and spirit of the invention. In other instances, well known 
features have not been described in detail so as not to obscure the invention. Whilst the 
invention may be preferably practised on flat files, it will be apparent to a person skilled in 
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the art that the invention may also be practised on databases. A database may be 
constructed from sets of flat file records. A relational database is a collection of related 
tables, each table being a set of flat files having the same structure. The method includes 
the step of: displaying a selected one of the predefined portions in a first display region. 
5 The display region preferably takes the form of an area of real estate on a computer screen 
(henceforth referred to as the "content frame"). The method also includes the step of 
displaying a view into a primary axis of the multidimensional space in which the displayed 
preferred portion is clearly marked. This second area of the computer screen shall be 
referred to as the "reference frame". Each frame has an associated "anchor", which is a 

10 title bar clearly indicating the nature of the view currently displayed in the frame. The 
reference anchor also contains tools for navigating the displayed axis. The method also 
includes the step of displaying a point on a primary axis of the multidimensional space for 
the displayed predefined portion. 

The method may be enhanced by displaying a second point on a second axis which 

15 relates to the first axis at the first point. The second axis represents time-based versions 
of the selected one of the predefined portions. Alternatively, the second axis represents 
amending legislation that was applied to the selected one of the predefined portions. In 
another example, the second axis represents case law that applied the selected one of the 
predefined portions. In further example, the second axis represents annotations to the 

20 selected one of the predefined portions. In a yet further example, the second axis 

represents entries of a subject index that are covered in the selected one of the predefined 
portions. 

The embodiment of the present invention allows for a primary axis (the combined 
hierarchical/sequential or normal axis). A "base node" may be selected by navigating the 

25 primary axis. The method then allows for one of a number of potential axes (associated 
with the base node) to be selected and subsequently navigated. The selection is 
accomplished by means of activating "links" in the displayed base node. The reference 
frame is redrawn to give a view of the members of the selected axis and one member of 
that axis is displayed. At any point it is possible to return to the primary axis and select a 

30 new base node. Alternatively, the currently displayed base node may be chosen as a new 
base node from which subsequent axes are derived. In this manner, any number of axes 
may be displayed and navigated without increasing the complexity of the screen view (i.e. 
only two frames are ever required). It is this quality which allows a complex dataset to be 
navigated by a non-specialist end user. 

27 



By way of example, a user may select a first node, corresponding to a provision, in 
the multidimensional space. The first node's locator is displayed in a first anchor to 
provide the user with a first point of reference. If the user is interested in different 
versions of the provision, the user may then move to second node on an orthogonal axis, 
5 being the Versions axis. The first anchor is updated and displays the locator of the second 
node. A second anchor displays the locator of the first node. The second anchor also 
displays the relationship between the first node and the second node. The user is provided 
with information which indicates the original provision that was being studied, the 
provision currently being studied and the current provision's relationship to the original 

10 provision. Thus, the first and second anchors and the information provided therein enable 
the user to navigate the multidimensional space. 

Where reference is made in any one or more of the accompanying drawings to 
steps and/or features, which have the same reference numerals, those steps and/or features 
have for the purposes of this description the same function(s) or operation(s), unless the 

15 contrary intention appears. 

The principles of the preferred method described herein have general applicability 
to electronic publishing. However, for ease of explanation, the steps of the preferred 
method are described with reference to navigating in a MALT publication. However, it is 
not intended that the present invention be limited to the described method. It will be 

20 appreciated by those skilled in the art that a publication could include a document or a 

database. The invention may apply to any hierarchical XML data where any of the nodes 
may change independently of other nodes in the hierarchy. Typical examples might 
include manuals and newspapers. For example, the invention may have application to the 
production and display of aircraft manuals. In this case, each node would be a set of 

25 maintenance instructions for a part or assembly. The axes might be part number; category 
(electrical, structural, etc.); location (Boeing 737, wing, wingtip assembly, eddy baffle, 
securing flange AX-703); airline (United, QANTAS); language (English, French). Since 
each commercial aircraft is in effect a one-off construct, the basic information needs to be 
reconfigured for each plane, each airline, etc. 

30 Before proceeding with a description of the embodiments, a brief review of 

terminology is discussed hereinafter. A dataset refers to the complete set of data that is to 
be navigated. A dataset has a complete set of discrete objects called nodes. The dataset 
may be viewed as a sparse multidimensional matrix, as is produced using the MALT 
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publishing method. In the example of this specification, the dataset preferably refers to a 
body of legislation designed for point in time searching. 

A node preferably corresponds to a particular legislative provision at a particular 
date. A base node is a particular node from which one or more viewing axes may be 
5 derived. 

A viewing axis is an ordered set of nodes derived from a single base node. The 
base node itself may or may not constitute part of the axis. For example, given a particular 
provision in time, three possible viewing axes are: the set of all provisions in force on the 
same date as the base node; the set of versions of the base provision in time; and the set of 
10 amending provisions most recently applied to the base provision. Further viewing axes 
may be practised, and may include case law that applied the provision, annotations to the 
provision and entries of a subject index that are covered in the provision. 

A provision, for the purposes of this system, is a unit of legislation having a 
heading and/or content, but not including text belonging to any sub-provision that is a 
15 predefined portion of text. A provision may be an Act, a schedule, a chapter, a section or 
other legislative unit. A provision has a scope in time, such that when a provision is 
amended, a new provision is created. A provision corresponds to a set of nodes, each node 
corresponding to a range of dates in the scope of the provision. 

Scope refers to a period of time during which a provision is in force. Thus, a given 
20 scope is usually expressed as start and end dates. A provision's scope is determined by the 
dates on which the provision commenced, was amended and/or was repealed. 

A locator is an identifier that is used to locate a particular node. For example, a 
locator may be a date, or a position such as the name of an Act and a section number. 

25 Multi-axis Viewing Interface 

Using the publication of legislation as an example, a provision is defined as being 
an amendable unit of legislation. At any given moment, the body of active legislation can 
be divided into provisions. Provisions also have a scope in time, so that when a provision 
is amended, the current provision goes out of scope and a new provision is created. The 
30 nodes of the dataset in this example are provisions with an associated date. Two locators 
are required to specify a particular node uniquely: a position (such as act and section 
number) and a date. 

There are a number of viewing axes associated with each node. As indicated in the 
explanation of terminology above, a viewing axis is defined as an ordered set of nodes that 
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can be derived from the current node. When XML data is converted to a series of fiat 
files, viewing axes are derived from the current node as a result of an intersection between 
two flat files. Two flat files intersect if common entries are contained in the fields of the 
respective flat files. For example, a legislation flat file may contain a field "Identifiers of 
cases that apply this provision". The legislation flat file shares a common entry with a 
case law flat file. Alternatively, the legislation flat file may contain a field "subjects 
covered in the provision". In this example, the legislation flat file shares a common entry 
with a subject index flat file. Alternatively, an amending legislation flat file may have a 
field "Identifiers of provisions amended by this provision" and share a common entry with 
the legislation flat file. 

In a preferred example, seven such viewing axes are: 

• Sequential (...; s 26; s 27; s 27A; ...), 

• Hierarchical (...; Corporations Act 1989; Part 2; Division 2.1; s 27), 

• Temporal (the set of versions of the current provision in time), 

• Source (the set of provisions which amend the current provision), 

• Case law (cases that apply the current provision), 

• Annotations (annotations to the current provision), and 

• Subject (Entries of a subject index that are covered in the current 
provision). 

The above axes are orthogonal in the sense that none can be directly derived from another. 
Thus, the temporal axis cannot be derived from the sequential axis. Moreover, members 
of the temporal axis are not simply those provisions sharing the same locator as the current 
provision. As a result of renumbering, members of the same temporal axis may possibly 
have widely differing locations. While the example uses two locators and four viewing 
axes, the MALTweb interface is capable of handling as many locators and axes as 
required. 

Having utilised MALT to construct a set of data encapsulating the above 
relationships, the problem is how to access this data in a meaningful way. To provide an 
untrained user with full multi-axis access to MALT type data whilst maintaining a 
consistent look and feel throughout, a view consisting of a two frame screen is provided. 

Fig. 1 Fig. 18 is a screenshot 400 1800 depicting a section of legislation in 

accordance with an embodiment of the invention. A content frame 440 1810 displays the 

content of the current node. In essence, this frame 44© 1810 constitutes a known portion 

of display "real estate". In the example of Fig. 1 Fig. 18 , the node corresponds to Section 
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59 of the Commonwealth Corporations Act 1989 and the node has a scope of 16 October 
1995 onwards. The scope indicates the time during which the provision is in force. The 
content anchor 40§ 1805 of the content frame 440 1810 displays the locators for the 
current content provision in a user friendly form, such as: 
5 Corporations Act 1989 (Cth): s 59 

(Scope: 16 Oct 1995 onwards) 

Situated above the content anchor ±Q$ 1805 is a reference frame 430 1820 , which 
contains a set of links 1821 corresponding to the members of a viewing axis 

10 associated with the current base node. Reference markers 4-33 1823 indicate which of the 
links 434- 1821 is currently selected. In the Normal view, the content node shown in the 
content frame is always the same as the base node for the reference frame. In the Version 
view, the content node and base node are initially the same, but deviate when a different 
version is selected. In the Source view, the base node is being amended and the content 

15 node is one of the amending provisions. 

The reference frame 430 1820 has a corresponding reference anchor 44# 1815 , 
which describes the current viewing axis and provides buttons 4-46 1816 , 4-4-8 1818 for 
navigating the sequential axis and button 4-42 1817 for accessing higher levels of the 
hierarchy. These levels can also be accessed via the links 434 1821 in the reference frame. 

20 In the example, the reference anchor 445 1815 indicates that the user is being shown a 
normal view of s59, as in force on 20 July 2000. This view also shows the search mode, 
in which the text "exercise of jurisdiction" has been located. The buttons 1 12, 113 1812, 
1813 allow access to the next or previous occurrence of this text, whilst button 444 1814 
cancels the search. The "hits" links 433 1822 in the reference frame allow rapid access to 

25 occurrences of the search text in other parts of the document. In this respect, the search 
mode acts very much like a separate viewing axis. The highlighting 406 1806 indicates 
the selected text. Finally, the links 107, 108 1807, 1808 allow access to the other viewing 
axes (in this case, Versions and Amendments). 

Where appropriate, the reference anchor 44# 1815 may indicate the base node of 

30 the viewing axis. The base node is the node from which the viewing axis is derived. For 
example, the reference anchor 54-5 2015 of Fig. 3 Fig. 20 , which shows a Source axis view 
of the same provision depicted in Fig. 1 Fig. 18 , displays the following information: 

Provisions amending (effective 16 Oct 1995) 
Corporations Act 1989 (Cth): s 59 
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This indicates that the Source axis being viewed by the user is derived from the 
base provision : Corporations Act, s59 [16 Oct 1995 onwards]. The content anchor 30§ 
2005 details the amending provision, which in this example is Corporations Legislation 
5 Amdt Act 1994 (Cth):Sch 1. 

The relationship of the base node and the content node depends on the view. In the 
Normal axis view, consisting of the sequential and hierarchical axes, the base node and the 
content node are always the same. In the Versions axis view, the base node and the 
content node may or may not be the same. 

10 A view is, therefore, defined as the display of a particular content node in relation 

to a specified axis. Each view may be uniquely identified from the following: the current 
content node, the current viewing axis, and the base node of the viewing axis. To further 
help the user in distinguishing the different viewing axes, the reference frame links may 
optionally vary in colour, content and indenting style among the views. 

15 Fig. 2 Fig. 19 shows a Version axis view 200 1900 of the provision depicted in Figr 

4 Fig. 18 . The content anchor 205 1905 indicates that the provision being displayed is, in 
fact, an earlier version of the provision displayed in Fig. 1 Fig. 18 . Thus, the information 
shown in the content frame 2+0 1910 has a different scope from the information shown in 
content frame 440 1810 of Fig. 1 Fig. 18 . Closer examination of the information of the 

20 content frame 240 1910 and the information of content frame 440 1910 indicates that 
amendments have in fact been made between the two versions of the provision. 

The reference frame 220 1920 of Fig. 2 Fig. 19 indicates that there are two 
versions of the provision, a first version with a scope of 1 January 1994 to 15 October 
1995 and a second version with a scope of 16 October 1995 to 31 December 2001. Each 

25 version of the provision is a distinct node on the Version axis. The reference anchor 245 
1915 indicates that the user is navigating along the Versions axis view of section 59. 

Fig. 3 Fig. 20 shows a Source axis view 300 2000 of the provision under 
consideration. The reference anchor 344 2015 of Fig. 3 Fig. 20 indicates to the user that 
the material being displayed relates to provisions amending the Corporations Act 1989 

30 (CTH); s 59. The reference frame 320 2020 indicates that there are three relevant nodes 
321, 322, 323 2021, 2022, 2023 on the source axis. Each node corresponds to a provision 
which amends the current provision. The amending provisions are not necessarily 
sequential and may be non-consecutive and/or in different schedules and/or in different 
Acts. The content anchor 304 2005 indicates that the current information being shown is 
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Schedule 1, Part 1, Item 15 of the Corporations Legislation Amendment Act 1994, 
corresponding to the first node 33J- 2021 shown in the reference frame 33© 2020 . The 
content of the amending act is displayed in the content frame 340 2010 . 

Thus, the multi-access viewing interface provides a user with content and reference 
components. Anchors uniquely identify the content node by position and date, and the 
viewing axis by base node and axis type. Furthermore, the reference frame is capable of 
displaying multiple viewing axes for a given base node, as illustrated in 
Figs. 1 3 Figs. 18-20 . 

Higher Level Scoping 

The MALT concept encapsulates the ability to store the contents of a sparse 
multidimensional matrix in a set of flat file records. As previously defined, the scope of a 
provision is a time period during which the given provision is in force. A problem arises 
relating to scoping a record which encompasses a number of lower level records. 

Consider as an example legislation marked up for point in time searching. The 
body of the legislation consists of provisions (or nodes), where each provision is an 
amendable unit of legislation. For the purposes of this example, each provision possesses 
the following four properties: 

• A single parent, or container provision in which the current provision resides. 
[The children of a provision are those provisions which have the current 
provision as the parent.] 

• A position within a provision's parent, and (optionally) an associated locator 
(eg. the fourth child provision of an Act may have the locator "Chapter 2A"). 

• A scope in time (i.e. start and end dates). 

• The content of the provision. 
The provisions are divided into three classes: 

• A single root node, which has no parent, but from which all other nodes 
ultimately descend; 

• A set of terminal nodes, which have no children; and 

• A set of higher level nodes which are neither the root node nor terminal. 
The legislation can then be said to form a tree descending from the root node and 
containing the terminal nodes at the ends of the root node's branches. 
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The scope of a terminal node is the period of time between the terminal node's 
start date and end date, inclusive. The root node is deemed to be always in scope. The 
scope of a node which is neither a terminal node nor a root node is problematic. 

For example, a chapter may encompass many sections, but the chapter's actual 
5 content, viewed in isolation as a record, is simply the chapter's title, including locator if 
present, and any notes or other attachments that apply to the chapter as a whole. All other 
content is contained indirectly via the chapter's descendant provisions, such as parts, 
sections and the like. 

Difficulty arises in determining the scope of the chapter node. In one sense, the 
10 scope of the chapter node is the sum of the scopes of the chapter node's descendants. A 
question then arises if, for example, the chapter's title is altered. The same applies to the 
case in which the abovementioned notes or other attachments are altered. 

One solution is to create a duplicate chapter with the altered title. While effective, 
this method has some major drawbacks. Firstly, it involves a great deal of unnecessary 
15 duplication of material. Since each child provision can have only one parent; new copies 
of every sub-level have to be made. The scope of both the original and duplicate sublevels 
then have to be split at the date of the chapter's title change. This in turn requires each 
sub-level to behave as though amended, even though the amendment only applies to the 
title of an ancestor level. 
20 A better solution is to create a new terminal sub-level of the chapter which 

contains just the title and associated text. This sub-level can then be scoped independently 
of the main level, and other sub-levels are unaffected. The sub-levels retain the same 
parent as the chapter level itself was not affected by the amendment. 

However, this still leaves open the question of what to do with the scope of the 
25 chapter level. Clearly a chapter, like any other provision, can be created or repealed. 
Thus, an amendment such as "repeal Chapter 2A" should end the scope of the chapter 
level as well as all of the chapter's descendants. 

The editors, however, may wish to leave a stub entry to mark the place of the 
former chapter thus: 

30 Chapter 2A 

[repealed] 

The scope of the stub clearly lies outside the scope of the chapter. There are three possible 
solutions: 
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• allow the [repealed] entry (which stands in place of a normal title) to live 
inside the chapter, even though the entry is out of the chapter's scope; 

• extend the scope of the chapter to encompass the scope of the stub; or 

• create a new chapter level containing just the stub. 

5 The first option creates significant inefficiencies in the design, since the scope of a sub- 
level cannot be assumed to lie within the scope of the sub-level's parent. The other two 
options give rise to potential conflicts between the stub and possible replacement chapters. 

Having delegated the title and other general notes to their own sublevels, all 
content has effectively been removed from the chapter. However, a chapter level is still 
10 required, as removing higher levels makes all terminal nodes direct children of the root. 
This in turn severely impacts on the usefulness of the data when mapped to a hierarchical 
form, such as XML. 

In addition, a higher level does contain one property, namely one or more locators 
("Chapter 2A" in the example). While this property can theoretically be delegated to yet 

15 another sub-level, the practical implications are significant. In particular, the locator 

reflects the ordering of the chapter amongst its siblings. If, for example, an amendment 
renumbers chapter 2A to chapter 4, this gives rise to the issue of whether the chapter 
comes before or after chapter 3 in either a flat file or in XML. For this reason, the locator 
is the sole property preserved by a higher level node throughout the higher level node's 

20 scope. If the position is changed, then a new level (and sub-levels) is created. 

This still leaves the problem of the scope of a higher level. For example, if 
Chapter 2A is repealed and a new, unrelated chapter 2A immediately takes the place of the 
repealed Chapter 2A, a problem is potentially presented as to two overlapping scopes for 
the same provision. The scope of the original node has to be terminated, otherwise there 

25 are two Chapter 2As in scope contemporaneously. The co-existence of two Chapter 2As 
poses a detrimental impact on the ability to navigate and search the legislation under 
consideration. In the situation in which the original Chapter 2A has a repeal stub, the 
original Chapter 2A's scope may overlap the new Chapter 2 A, since the stub may continue 
indefinitely in time. Among many possibilities, a repeal stub may be provided while 

30 Chapter 2A does not exist. 

Other problems include: repeal or substitution of a higher level node; 
renumbering/relocation of a higher level node; renaming (without renumbering/relocation) 
of a higher level node; elevation or demotion of a higher level node within the hierarchy, 
e.g. changing a part to a chapter or a division to a subdivision; and insertion/removal of an 
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intermediate level heading node, requiring that nodes which follow and are/were, 
according to their type, inferior to that heading node become/ cease to be children of that 
node. 

In order to resolve these problems, the following design rule is applied: Higher 
level nodes may have neither scope nor content. In other words, a non-terminal node 
must be a container only. A non-terminal node's only properties are a parent indicator, a 
position within the parent, and (optionally) a locator. Any content notionally belonging to 
such a node, such as a chapter title, is assigned to a new (terminal) child node. A 
(terminal) child node may contain a label, which is preferably a title, but can be or include 
other data related to the parent node. The new child node preserves the scope of the title, 
so (for example) a single chapter may possess a number of (temporally disjoint) title 
nodes. 

Higher level scoping has a number of surprising but useful consequences. In 
particular, a higher level provision is, in itself, not subject to amendment. Thus, an 
instruction such as "Repeal Chapter 2A" actually terminates the scope of all of Chapter 
2A's constituent terminal nodes. The chapter node, having no scope of its own, is 
unaffected. 

Additionally, the previously described problem pertaining to the overlapping scope 
of the 2A repeal stub disappears. Embodiments of the invention utilise the following 
approaches. When Chapter 2A is repealed, the associated scope of all terminal nodes 
within Chapter 2A is terminated. In a first embodiment, a new Chapter 2A is enacted 
immediately after the original chapter is terminated. The new Chapter 2A has an 
associated scope commencing on the day after which the original Chapter 2A was 
repealed. In a second embodiment, a repeal stub is introduced. A repeal stub in the 
preferred embodiment is a title with an attribute marking this title as being of the type 
"repeal stub". The repeal stub has an associated scope with a start date corresponding to 
the date after which Chapter 2A was repealed. The repeal stub has the Chapter 2A node as 
a parent. If a new Chapter 2A is later enacted, the scope of the repeal stub is terminated 
and the scope of the terminal nodes of the new Chapter 2A will begin on the day after the 
end date of the repeal stub's scope. 

Thus, a request "for Chapter 2A on date X" returns a description of Chapter 2A 
that was valid on that date. In the event that the request is for a date on which the chapter 
is repealed, the fact that the chapter is not in force, having been repealed on or before that 
date, will be returned. 
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A portion of Document Type Definition (DTD) code which is used to enable 
higher level scoping appears in Tables 1 to 7 2 to 8 below: 



¥abte-l Table 2 

< i - - ~~ 

######################## ################################# 
ENTITY: hlev-id 

PURPOSE: Concatenation of the elements that make the 
Identification of a higher level element. Only to be used for levels in 
which the <desc> can be MALTed - for levels in which the whole level 
should be MALTed (ie, section, reg, schedule) and for their sub-levels, 
use %lev-id; . 

########################################################### 

— > 

<! ENTITY % hlev-id 

"(target*, label?, (desc, % amendments ;)*) " 

> 



Tabled Table 3 



< ! ELEMENT act 

(%hlev-id; , 
(%hnote; | %raw,*)*, 
(longtitle, % amendments ; ) + , 
preamble* , 

(chapter* | part* | section*) , 
(schedule* | include+)*, 
hist* ) 

> 

<!ATTLIST act 
j uris 

(cth | nsw | vie | qld | sa | wa | tas | act | nt | imp) 
#REQUIRED 

year 

CDATA 
#REQUIRED 
number 

CDATA 
#REQUIRED 

> 



Tabled Table 4 



< ! ELEMENT regulations 
(%hlev-id; , 
(%hnote; | %raw;)*, 

(chapter* | part* | reg*), 
(schedule* | include+) * 
) 

> 

< 1ATTLIST regulations 
juris 

(cth | nsw | vie | qld | sa | wa | tas | act | nt | imp) 
#REQUIRED 

year 

CDATA 
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#REQUIRED 
number 

CDATA 
#REQUIRED 

> 

< ! ELEMENT chapter 
(%hlev-id; , 
(%hnote; ) * , 

( ( (Isecreg; ) * , part*) | article+) ) 

> 

< ! ATTLIST chapter 
id 

CDATA 
#IMPLIED 
next- id 

CDATA 
#IMPLIED 



Table 4 Table 5 



<! ELEMENT part 
(%hlev-id; , 
hist*, 

( ( ( %secreg; ) * , division*) | 
(article* | item+ | clause*) | 
(guide+) | 
(unconverted+ ) ) ) 

> 

< 1 ATTLIST part 
id 

CDATA 
#IMPLIED 
next - id 

CDATA 
#IMPLIED 



Tabled Table 6 



<! ELEMENT division 
(%hlev-id; , 
(p | %hnote;)*, 
( { (%secreg; ) * , subdivn*) | 
(clause*, item*))) 

> 

< ! ATTLIST division 
id 

CDATA 
#IMPLIED 
next- id 

CDATA 
#IMPLIED 
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¥ebk^6 Table 7 



< ! ELEMENT subdivn 
(%hlev-id; , 
( %hnote ; ) * , 

<(%secreg;)+ | clause+) ) 

> 

< ! ATTLIST subdivn 
id 

CDATA 
#IMPLIED 
next -id 

CDATA 
#IMPLIED 



Tabled Table 8 



##################################################################### 

ELEMENT: desc 

PURPOSE: Defines the "description" of a level. 
ATTRIBUTES : 

%date-atts; - defines the start and end dates for this version 

of the description. 

##################################################################### 

— > 

< i ELEMENT desc 

(# PCDATA | %refs; | %effect; | quote)* 

> 

<i ATTLIST desc 
%date-atts ; 



The DTD has been altered such that scoping is transferred from the higher level nodes to 
terminal nodes. 

Consider an example consisting of an Act with two chapters, the second chapter 
5 containing two sections, as shown by the system #00 2100 of Fig. 4 Fig. 21 . A root node 
#49 2110 represents the Act. The root node §40 2110 has no parent, and all other nodes 
descend from the root node 5+0 21 10 . The first chapter of the Act is represented by a 
higher level node #30 2120 . As a higher level node, node #20 2120 has neither scope nor 
content. Node #20 2120 has the following properties: a parent, being the Act node §40 
10 2110 : a position within the parent node §40 21 10 , being 1; and an optional locator, being 
"Chapter 1". Node §20 2120 has two descendant nodes 522, 521 2122. 2124 . Node #33 
2122 has the following properties: a parent, being the node #30 2120 identified by its 
locator "Chapter 1"; a position within the parent node #30 2120, being 1; an optional 
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locator, being "Chapter 1 Description"; scope, being 1 January 1998 onwards; and content 
relating to the title or textual description of the first chapter of the Act under consideration. 
Node 524 2124 has the following properties: a parent, being the node §2© 2120 identified 
by its locator "Chapter 1"; a position within the parent node 520 2120 , being 2; an optional 
5 locator, being "Chapter 1 Note"; scope, being 1 January 1998 onwards; and content 
providing general notes or comments pertaining to the first chapter of the Act under 
consideration. 

A second higher level node 550 2130 represents the second chapter of the Act. 
Node 550 2130 has two sections. Node 550 2130 has the following properties: parent, 

10 being the Act node 540 21 10 ; a position within the parent node 540 21 10 , being 2; and an 
optional locator, being "Chapter 2A". Node 530 2130 has five child nodes: 532, 53 4 , 536, 
510 and 550 2132, 2134, 2136, 2140 and 2150 . each of which is a terminal node in this 
example. Node 553 2132 has the properties: parent, being Chapter 2A; a position within 
the parent, being 1; an optional locator, being "Chapter 2A description"; scope, being 1 

15 January 1998 - 30 June 1998; and content, being "Company Registration". Node 554 

2134 has the properties: parent, being Chapter 2A; a position within the parent, being 2; an 
optional locator, being "Chapter 2A description"; scope, being 1 July 1998 onwards; and 
content, being "Registering a Company". Node 556 2136 has the properties: parent, being 
Chapter 2 A; a position within the parent, being 3; an optional locator, being "Chapter 2A 

20 note"; scope; and content. Node 540 2140 has the properties: parent, being Chapter 2A; a 
position within the parent, being 4; an optional locator, being "Section 1 1"; scope; and 
content. Node 550 2150 has the properties: parent, being Chapter 2A; a position within 
the parent, being 5; an optional locator, being "Section 12"; scope; and content. 

The different scopes of nodes 532 and 534 2132 and 2134 allow nodes 532, 53 4 

25 2132, 2134 to co-exist, without overlapping. Nodes 532, 53 4 2132, 2134 may share the 
same locator, but the combination of locator and scope uniquely identifies the nodes. 
Nodes 532, 53 4 2132, 2134 reflect the amendment of the title of Chapter 2 A from 
"Company Registration" to "Registering a Company". The scopes of nodes 532, 53 4 
2132, 2134 indicate that the amendment came into effect on 1 July 1998. 

30 In accordance with a further embodiment, higher level scoping is extended to 

facilitate commentaries, subject indices and similar material. When considering 
legislation, any amendment results in the production of a modified portion. However, 
when considering commentaries, two types of amendment to the commentary are possible. 
In the first scenario, corresponding to the legislation example, the scope of the current 
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predefined portion of commentary is terminated and a new predefined portion is provided. 
The new predefined portion has a scope commencing on the day after the expiration of the 
current predefined portion. In the second possible scenario, the current predefined portion 
of the commentary is amended without a second predefined portion being created. 
5 The scope of commentary portions is extended to include three dates: a start date, an 

update date and an end date. Referring to Fig. 5A Fig. 22A , a screen shot 560 2260 shows 
a commentary. The commentary was created on 1 July 2000, as seen from the amendment 
bar 565 2265 . The commentary has the following scope properties: start date of 1 July 
2000, no update date and no end date. Fig. 5B Fig. 22B shows a screen shot 570 2270 of 

10 the commentary of Fig. 5A Fig. 22 A at a later date. The amendment bar 575 2275 

indicates that the commentary was last updated on 1 September 2000. Thus, the scope of 
the commentary now has a start date of 1 July 2000, an update date of 1 September 2000 
and no end date. Fig. 5C Fig. 22C shows a further screen shot 580 2280 of the 
commentary of Fig. 5A Fig. 22A and 5© 22B at a yet later date. The amendment bar 584 

15 2284 indicates that at least one further amendment has been applied to the commentary 
since the update of 1 September 2000 indicated at 575 2275 in Fig. 5B Fig. 22B . The 
amendment bar 585 2285 of Fig. 5C Fig. 22C shows that the last update date of the 
commentary is 1 October 2000. Therefore, the scope properties of the commentary now 
read: First portion: start date of 1 July 2000, end date of 30 September 2000; Second 

20 portion: start date of 1 October 2000, and no end date. 

In a further embodiment, XML data may be divided into predefined portions and 
stored as a collection of flat files. In an example, the flat files take the form of a relational 
database. There is a one to one correspondence between the XML data and the relational 
database. The hierarchy of the XML data is expressed via the implementation of higher 

25 level scoping. A single record is provided with an identifier and other terminal nodes are 
provided in which to store the remainder of the information. 

The process for navigating in a multidimensional space containing an electronic 
publication formed from predefined portions of text-based data encoded using a markup 
language can be implemented using a computer program product in conjunction with a 

30 computer system 600 2300 as shown in Fig. 6 Fig. 23 . In particular, the process for 

navigating in a multidimensional space containing an electronic publication formed from 
predefined portions of text-based data encoded using a markup language can be 
implemented as software, or computer readable program code, executing on the computer 
system 60© 2300 . 



Similarly, the process for publishing an electronic publication formed from 
predefined portions of text-based data encoded using a markup language may also be 
implemented using a computer program product in conjunction with the computer system 
690 2300 shown in Fig. 6 Fig. 23 . 
5 The computer system 600 2300 includes a computer 65© 2350 , a video display 6±© 

2310 and input devices 630, 632 2330, 2332 . In addition, the computer system 600 2300 
can have any of a number of other output devices including line printers, laser printers, 
plotters, and other reproduction devices connected to the computer 65© 2350 . The 
computer system 6©© 2300 can be connected to one or more other computers via a 

10 communication input/output (I/O) interface 664 2364 using an appropriate communication 
channel 64© 2340 such as a modem communications path, an electronic network, or the 
like. The network may include a local area network (LAN), a wide area network (WAN), 
an Intranet, and/or the Internet 62© 2320 . 

The computer 65© 2350 includes the control module 668 2368 , a memory 67© 

15 2370 that may include random access memory (RAM) and read-only memory (ROM), 

input/output (I/O) interfaces 66 4 , 672 2364, 2372 , a video interface 66© 2360 , and one or 
more storage devices generally represented by the storage device 663 2362 . The control 
module 668668 2368 is implemented using a central processing unit (CPU) that executes 
or runs a computer readable program code that performs a particular function or related set 

20 of functions. 

The video interface 66© 2360 is connected to the video display 64© 2310 and 
provides video signals from the computer 65© 2350 for display on the video display 64© 
2310 . User input to operate the computer 650 2350 can be provided by one or more of the 
input devices 630, 632 2330, 2332 via the I/O interface 672 2372 . For example, a user of 

25 the computer 65© 2350 can use a keyboard as I/O interface 63© 2330 and/or a pointing 
device such as a mouse as I/O interface 632 2332 . The keyboard and the mouse provide 
input to the computer 65© 2350 . The storage device 662 2362 can consist of one or more 
of the following: a floppy disk, a hard disk drive, a magneto-optical disk drive, CD-ROM, 
magnetic tape or any other of a number of non-volatile storage devices well known to 

30 those skilled in the art. Each of the elements in the computer system 65© 2350 is typically 
connected to other devices via a bus 68© 2380 that in turn can consist of data, address, and 
control buses. 

The method steps for navigating in a multidimensional space containing an 
electronic publication formed from predefined portions of text-based data encoded using a 
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markup language are effected by instructions in the software that are carried out by the 
computer system 600 2300 . Again, the software may be implemented as one or more 
modules for implementing the method steps. 

In particular, the software may be stored in a computer readable medium, including 
5 the storage device 662 2362 or that is downloaded from a remote location via the interface 
664 2364 and communications channel 640 2340 from the Internet 620 2320 or another 
network location or site. The computer system 600 2300 includes the computer readable 
medium having such software or program code recorded such that instructions of the 
software or the program code can be carried out. The use of the computer system 600 

10 2300 preferably effects advantageous apparatuses for navigating a multidimensional space 
containing an electronic publication formed from predefined portions of text based data 
encoded using a markup language and for publishing an electronic publication formed 
from predefined portions of text based data encoded using a markup language in 
accordance with the embodiments of the invention. 

15 The computer system 600 2300 is provided for illustrative purposes and other 

configurations can be employed without departing from the scope and spirit of the 
invention. The foregoing is merely an example of the types of computers or computer 
systems with which the embodiments of the invention may be practised. Typically, the 
processes of the embodiments are resident as software or a computer readable program 

20 code recorded on a hard disk drive as the computer readable medium, and read and 

controlled using the control module 668 2368 . Intermediate storage of the program code 
and any data including entities, tickets, and the like may be accomplished using the 
memory 670 2370 , possibly in conceit with the storage device 662 2362 . 

In some instances, the program may be supplied to the user encoded on a CD- 

25 ROM or a floppy disk (both generally depicted by the storage device 662- 2362) , or 

alternatively could be read by the user from the network via a modem device connected to 
the computer 650 2350 . Still further, the computer system 600 2300 can load the software 
from other computer readable media. This may include magnetic tape, a ROM or 
integrated circuit, a magneto-optical disk, a radio or infra-red transmission channel 

30 between the computer and another device, a computer readable card such as a PC card, 
and the Internet 620 2320 and Intranets including email transmissions and information 
recorded on Internet sites and the like. The foregoing are merely examples of relevant 
computer readable media. Other computer readable media may be practised without 
departing from the scope and spirit of the invention. 
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The process for navigating in a multidimensional space containing an electronic 
publication formed from predefined portions of text-based data encoded using a markup 
language can be realised in a centralised fashion in one computer system 600 2300 , or in a 
distributed fashion where different elements are spread across several interconnected 
computer systems. 

The process for publishing an electronic publication formed from predefined 
portions of text-based data encoded using a markup language may also be implemented 
using a computer program product in conjunction with the computer system 600 2300 of 
Fig. 6 Fig. 23 in a manner similar to that which has just been described. 

Computer program modules or computer program in the present context mean any 
expression, in any language, code or notation, of a set of instructions intended to cause a 
system having an information processing capability to perform a particular function either 
directly or after either or both of the following: a) conversion to another language, code or 
notation or b) reproduction in a different material form. 

In the foregoing manner, a method, an apparatus, and a computer program product 
for navigating in a multidimensional space containing an electronic publication formed 
from predefined portions of text-based data encoded using a markup language are 
disclosed. Further, a method, an apparatus, and a computer program product for 
publishing an electronic publication formed from predefined portions of text-based data 
encoded using a markup language are disclosed. While only a small number of 
embodiments are described, it will be apparent to those skilled in the art in view of this 
disclosure that numerous changes and/or modifications can be made without departing 
from the scope and spirit of the invention. 
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The process for navigating in a multidimensional space containing an electronic 
publication formed from predefined portions of text-based data encoded using a markup 
language can be realised in a centralised fashion in one computer system 600 2300 , or in a 
distributed fashion where different elements are spread across several interconnected 
computer systems. 

The process for publishing an electronic publication formed from predefined 
portions of text-based data encoded using a markup language may also be implemented 
using a computer program product in conjunction with the computer system 600 2300 of 
Fig. 6 Fig. 23 in a manner similar to that which has just been described. 

Computer program modules or computer program in the present context mean any 
expression, in any language, code or notation, of a set of instructions intended to cause a 
system having an information processing capability to perform a particular function either 
directly or after either or both of the following: a) conversion to another language, code or 
notation or b) reproduction in a different material form. 

In the foregoing manner, a method, an apparatus, and a computer program product 
for navigating in a multidimensional space containing an electronic publication formed 
from predefined portions of text-based data encoded using a markup language are 
disclosed. Further, a method, an apparatus, and a computer program product for 
publishing an electronic publication formed from predefined portions of text-based data 
encoded using a markup language are disclosed. While only a small number of 
embodiments are described, it will be apparent to those skilled in the art in view of this 
disclosure that numerous changes and/or modifications can be made without departing 
from the scope and spirit of the invention. 
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1. A system for publishing electronic information, comprising: 

a plurality of predefined portions of data with each predefined portion being encoded 

with at least one linking means, and, for each predefined portion, said each predefined 
portion is stored and, where such predefined portion has been modified, each such 
5 modified predefined portion is stored; and 

a plurality of attributes, each attribute being a point on an axis of a multidimensional 

space for organising said data. 

2. The system according to claim 1 comprising means for searching within the 

system. 

10 3. The system according to claim 2 wherein said searching means uses one or 

more attributes. 

4. The system according to claim 2 or 3 wherein said searching means uses any 

predefined portion, any modification of a predefined portion, or any word or phrase within 
such predefined portion or such modification. 

15 5. The system according to claim 1 further comprising means for searching at 

least one of said predefined portions of said data using said plurality of attributes, wherein 
said plurality of attributes are coupled to each of said predefined portions by said 
respective linking means, and for retrieving one or more of said predefined portions using 
said plurality of attributes to define a point in said multidimensional space. 

20 6. The system according to any one of claims 1 to 3 and 5, wherein said plurality 

of predefined portions of said data are encoded using Standard Generalised Markup 
Language (SGML) OR XML. 

7. The system according to claim 6, wherein said data is encoded using one or 

more Document Type Definitions (DTD) or Style Sheet Mechanisms (SSM). 

25 8. The system according to any one of claims 1 to 3 and 5. wherein said linking 

means comprises any piece of information additional to the body of the data. 

9. The system according to claim 8, wherein said linking means is a code or 

markup that allows departure and destination points to be created between portions of 
data. 

30 10. The system according to any one of claims 1 to 3 and 5, wherein said at least 

one linking means comprises an identification code for said respective predefined portion. 

11. The system according to any one of claims 1 to 3 and 5, wherein a first 

database comprises said plurality of predefined portions of data. 
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12. The system according to claim 11, wherein a second database comprises said 

plurality of attributes for managing said first database. 

13. The system according to any one of claims 1 to 3 and 5, wherein said 

predefined portions are encoded with one or more attributes. 

5 14. The system according to any one of claims 1 to 3 and 5. wherein said 

respective predefined portion is changed by performing one of the group consisting of 
adding at least one attribute to said respective predefined portion, deleting at least one 
attribute from said respective predefined portion, and modifying at least one of the 
attributes of said respective predefined portion. 

10 15. The system according to any one of claims 1 to 3 and 5, wherein said 

respective predefined portion is changed by performing one of the group consisting of 
adding data to said respective predefined portion, deleting data from said respective 
predefined portion, and modifying data of said respective predefined portion. 
16. The system according to any one of claims 1 to 3 and 5, wherein said data 

15 comprises legislation. 

17. The system according to claim 16, wherein each of said plurality of predefined 

portions of data is a respective provision of said legislation. 

18. The system according to claim 17, wherein said provision is a section or 

schedule of an Act, or a regulation or schedule of a Regulations). 

20 19. The system according to any one of claims 1 to 3 and 5, wherein said system is 

implemented using a general purpose computer. 

20. A recording medium for publishing electronic information, comprising: 

a plurality of predefined portions of data with each predefined portion being encoded with 
at least one linking means, and, for each predefined portion, said each predefined portion 
25 is stored and, where such predefined portion has been modified, each such modified 
predefined portion is stored; and 

a plurality of attributes, each attribute being a point on an axis of a multidimensional space 
for organising said data.. 

21. The recording medium according to claim 20 wherein means for searching can 

30 be used to search the recording medium. 

22. The recording medium according to claim 21 wherein said searching means 

uses one or more attributes. 
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23. The recording medium according to claim 21 or 22 wherein said searching 

means uses any predefined portion, any modification of a predefined portion, or any word 
or phrase within such predefined portion or such modification. 

24. The recording medium according to claim 20 further comprising means for 

5 searching at least one of said predefined portions of data uses said plurality of attributes, 
wherein said plurality of attributes are coupled to each of said predefined portions by said 
respective linking means, and for retrieving one or more of said predefined portions using 
said plurality of attributes to define a point in said multidimensional space. 

25. The recording medium according to any one of claims 20 to 22 and 24, 

10 wherein said plurality of predefined portions of said data are encoded using Standard 
Generalised Markup Language (SGML) OR XML. 

26. The recording medium according to claim 25, wherein said data is encoded 

using one or more Document Type Definitions (DTD) or Style Sheet Mechanisms (SSM). 

27. The recording medium according to any one of claims 20 to 22 and 24, 

15 wherein said linking means comprises any piece of information additional to the body of 
the data. 

28. The recording medium according to claim 27, wherein said linking means is a 

code or markup that allows departure and destination points to be created between portions 
of data. 

20 29. The recording medium according to any one of claims 20 to 22 and 24, 

wherein said at least one linking means comprises an identification code for said 
respective predefined portion. 

30. The recording medium according to any one of claims 20 to 22 and 24, 

wherein a first database comprises said plurality of predefined portions of data. 

25 31. The recording medium according to claim 30, wherein a second database 

comprises said plurality of attributes for managing said first database. 

32. The recording medium according to any one of claims 20 to 22 and 24, 

wherein said predefined portions are encoded with one or more attributes. 

33. The recording medium according to any one of claims 20 to 22 and 24, 

30 wherein said respective predefined portion is changed by performing one of the group 

consisting of adding at least one attribute to said respective predefined portion, deleting at 
least one attribute from said, respective predefined portion, and modifying at least one of 
the attributes of said respective predefined portion. 
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34. The recording medium according to any one of claims 20 to 22 and 24, 

wherein said respective predefined portion is changed by performing one of the group 
consisting of adding data to said respective predefined portion, deleting data from said 
respective predefined portion, and modifying data of said respective predefined portion. 

5 35. The recording medium according to any one of claims 20 to 22 and 24, 

wherein said data comprises legislation. 

36. The recording medium according to claim 35, wherein each of said plurality of 

predefined portions of data is a respective provision of said legislation. 

37. The recording medium according to claim 36, wherein said provision is a 

10 section or schedule of an Act, or a regulation or schedule of a Regulationfs). 

38. The recording medium according to any one of claims 20 to 22 and 24, 

wherein said recording medium is implemented using a general purpose computer. 

39. The recording medium according to any one of claims 20 to 22 and 24, 

wherein said recording medium is made from one of the group consisting of magnetic 

15 media, optical media, and magneto-optical media. 

40. A method fur publishing electronic information, comprising the steps of: 

providing a plurality of predefined portions of data with each predefined portion being 
encoded with at least one linking means, and, for each predefined portion, said each 
predefined portion is stored and, where such predefined portion has been modified, each 

20 such modified predefined portion is stored; and 

providing a plurality of attributes, each attribute being a point on an axis of a 
multidimensional space for organising said data. 

41. The method according to claim 40 comprising the step of searching said data. 

42. The method according to claim 41 wherein said searching step uses one or 

25 more attributes. 

43. The method according to claim 41 or 42 wherein said searching step uses any 

predefined portion, any modification of a predefined portion, or any word or phrase within 
such predefined portion or such modification. 

44. The method according to claim 40 further comprising the step of searching at 

30 least one of said predefined portions of said data using said plurality of attributes, wherein 
said plurality of .attributes are coupled to each of said predefined portions by said 
respective linking means, and for retrieving one or more of said predefined portions using 
said plurality of attributes to define a point in said multidimensional space. 

48 



45. The method according to any one of claims 40 to 42 and 44, wherein said 

plurality of predefined portions of said data are encoded using Standard Generalised 
Markup Language (SGML) OR XML. 

46. The method according to claim 45, wherein said data is encoded using one or 

5 more Document Type Definitions (DTD) or Style Sheet Mechanisms (SSM). 

47. The method according to any one of claims 40 to 42 and 44, wherein said 

linking means comprises any piece of information additional to the body of the data. 

48. The method according to claim 47 wherein said linking means is a code or 

markup that allows departure and destination points to be created between portions of 
10 data. 

49. The method according to any one of claims 40 to 42 and 44, wherein said at 

least one linking means comprises an identification code for said respective predefined 
portion. 

50. The method according to any one of claims 40 to 42 and 44, wherein a first 

15 database comprises said plurality of predefined portions of data. 

51. The method according to claim 50, wherein a second database comprises said 

plurality of attributes for managing said first database. 

52. The method according to any one of claims 40 to 42 and 44, wherein said 

predefined portions are encoded with one or more attributes. 

20 53. The method according to any one of claims 40 to 42 and 44, wherein said 

respective predefined portion is changed by performing one of the group consisting of 
adding at least one attribute to said respective predefined portion, deleting at least one 
attribute from said respective predefined portion, and modifying at least one of the 
attributes of said respective predefined portion. 

25 54. The method according to any one of claims 40 to 42 and 44, wherein said 

respective predefined portion is changed by performing one of the group consisting of 
adding data to said respective predefined portion, deleting data from said respective 
predefined portion, and modifying data of said respective predefined portion. 
55. The method according to any one of claims 40 to 42 and 44, wherein said data 

30 comprises legislation. 

56. The method according to claim 55, wherein each of said plurality of 

predefined portions of data is a respective provision of said legislation. 

57. The method according to claim 56, wherein said provision is a section or 

schedule of an Act, or a regulation or schedule of a Regulation(s). 
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58. The method according to any one of claims 40 to 42 and 44, wherein said 

method is implemented using a general purpose computer. 
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APPENDIX A 

Example Research 

SOCIAL SECURITY ACT 1991 No 46 

Updated as at 9 August 1996 

A 1 . Amendments to Section at 9/8/96 

S.4 am. Nos. 74, 1 16 and 194. 1991: No. 81. 1992; 

No. 36, 1993: Nos. 55. 63 and 184. 1994; Nos. 

104 and 105. 1995 



A 2. Amendments to Section at 10/7/95 

10 S.4 am. Nos. 74. 1 16 and 194. 1991 : No. 81 . 

1992; No. 36. 1993: Nos. 55. 63 and 184. 

1994 



B. Commencement Information for Act No 105 of 1995 contained in Reprint 

Social Securitv(Non-Budqet Measures) Legislation Amendment Act 1995 

15 Number Year Date of Assent Commencement 

105 1 995 29 Sept 1 995 Subdiv. A of Div. 2 of Part 2 (s. 

4): 1 July 1993 



Ss. 8 and 9: 1 July 1995 



S. 10: 1 Apr 1993 



20 Div. 5 of Part 2 (ss. 12 and 13): 

20 Sept 1 994 (ze) 



Ss. 17(c). (d) and 18: 1 Jan 1996 



Div. 1 5 of Part 2 (s. 37): 29 Nov 1 993 



Div. 18 of Part 2 (ss. 41-48): 20 Mar 1995 



25 S. 49 (a): 12 Mar 1992 

S. 49 (b): 1 July 1992 



S. 49(c): 28 Jan 1993 



S. 49(d): 1 Mar 1993 



S. 49(e): 24 Dec 1993 



30 S. 49(f): 1 Jan 1994 

Remainder: Roval Assent 

C 1. Text of Section at 9/8/96 

bold text indicates amendments made by NO 105 of 1995. 

35 SECT 4 

Family relationships definitions-couples 

4. (1 ) (1) In this Act, unless the contrary intention appears: 

"approved respite care" has the meaning given by subsection (9): 
"armed services widow" means a woman who was the partner of: 
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(a) a person who was a veteran for the purposes of any provisions of the Veterans' 
Entitlements Act: or 

(b) a person who was a member of the forces for the purposes of Part IV of that Act: or 

(c) a person who was a member of a peacekeeping force for the purposes of Part IV of that 
5 Act: immediately before the death of the person: 

"armed services widower" means a man who was the partner of: 

(a) a person who was a veteran for the purposes of any provisions of the Veterans' 
Entitlements Act: or 

(b) a person who was a member of the Forces for the purposes of Part IV of that Act: or 
10 (c) a person who was a member of a peacekeeping force for the purposes of Part IV of that 

Act: immediately before the death of the person: 

"illness separated couple" has the meaning given by subsection (7): 

"member of a couple" has the meaning given by subsections (2). (3). OA) [reference to new 
section added! and (6): 

15 "partner", in relation to a person who is a member of a couple, means the other member of the 

couple: 

"partnered" has the meaning given by subsection (1 1 ): 

"partnered (partner getting benefit)" has the meaning given by subsection (1 1 ): 
"partnered (partner getting neither pension nor benefit)" has the meaning given by subsection 
20 (11): 

"partnered (partner getting pension)" has the meaning given by subsection (11): 
"partnered (partner getting pension or benefit)" has the meaning given by subsection (1 1 ): 
"partnered (partner in gaol)" has the meaning given bv subsection (11): 
"respite care couple" has the meaning given by subsection (8). 

25 

Member of a couple-general 

4 (2) Subject to subsection (3), a person is a member of a couple for the purposes of this Act 

it 

(a) the person is legally married to another person and is not, in the Secretary's opinion 
30 (formed as mentioned in subsection (3)). living separately and apart from the other person on a 

permanent or indefinite r Words added! basis: or 

(b) all of the following conditions are met: 

(i) the person has a relationship TWords is living replaced! with a person of the 
opposite sex (in this paragraph called the "partner"): 
35 (ii) the person is not legally married to the partner: 

(iii) the relationship between the person and the partner is. in the Secretary's opinion 
(formed as mentioned in subsections (3) and (3A)fWords addedl). a marriage-like relationship: 

(iv) both the person and the partner are over the aoe of consent applicable in the State or 
Territory in which thev live: 
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(v) the person and the partner are not within a prohibited relationship for the purposes of 
section 23B of the Marriage Act 1 961 . 

Note: a prohibited relationship for the purposes of section 23B of the Marriage Act 1961 is a 
relationship between a person and: 
5 . an ancestor of the person: or 

. a descendant of the person: or 

. a brother or sister of the person (whether of the whole blood or the part-blood). 

Member of a couple-criteria for forming opinion about relationship 
10 4 (3) In forming an opinion about the relationship between 2 people for the purposes of 

paragraph (2) (a) or subparagraph (2) lb) (iii). the Secretary is to have regard to all the 
circumstances of the relationship including, in particular, the following matters: 

(a) the financial aspects of the relationship, including: 

(0 any joint ownership of real estate or other major assets and any joint liabilities: and 
15 (ii) any significant pooling of financial resources especially in relation to major financial 

commitments: and 

(iii) any legal obligations owed by one person in respect of the other person: and 

(iv) the basis of any sharing of dav-to-dav household expenses: 

(b) the nature of the household, including: 

(i) any joint responsibility for providing care or support of children: and 

(ii) the living arrangements of the people: and 

(iii) the basis on which responsibility for housework is distributed: 

(c) the social aspects of the relationship, including: 

(i) whether the people hold themselves out as married to each other: and 

(ii) the assessment of friends and regular associates of the people about the nature of their 
relationship: and 

(iii) the basis on which the people make plans for, or engage in. joint social activities: 

(d) any sexual relationship between the people: 

(e) the nature of the people's commitment to each other, including: 
30 (i) the length of the relationship: and 

(ii) the nature of any companionship and emotional support that the people provide to each 
other: and 

(iii) whether the people consider that the relationship is likely to continue indefinitely: and 

(iv) whether the people see their relationship as a marriage-like relationship. 

35 4 (3A) The Secretary must not form the opinion that the relationship between a person 

and his or her partner is a marriage-like relationship if the person is living separately and 
apart from the partner on a permanent or indefinite basis. fSubsection addedl 
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C 2. Text of Section at 10/7/95 prior 

40 SECT 4 
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Family relationships definitions - couples 
4. SECT 4 

Family relationships definitions-couples 
4. (1) In this Act, unless the contrary intention appears: 
5 "approved respite care" has the meaning given by subsection (9): 

"armed services widow" means a woman who was the partner of: 

(a) a person who was a veteran for the purposes of any provisions of the Veterans' 
Entitlements Act: or 

(b) a person who was a member of the forces for the purposes of Part IV of that Act: or 

10 (c) a person who was a member of a peacekeeping force for the purposes of Part IV of that 

Act: immediately before the death of the person: 

"armed services widower" means a man who was the partner of: 

(a) a person who was a veteran for the purposes of any provisions of the Veterans' 

Entitlements Act: or 

15 (b) a person who was a member of the Forces for the purposes of Part IV of that Act: or 

(c) a person who was a member of a Peacekeeping Force for the purposes of Part IV of that 
Act: immediately before the death of the person: 

"illness separated couple" has the meaning given by subsection (7): 
"member of a couple" has the meaning given by subsections (2), (3). and (6): 
20 "partner", in relation to a person who is a member of a couple, means the other member of the 

couple: "partnered" has the meaning given by subsection (1 1 ); 

"partnered (partner getting benefit)" has the meaning given by subsection (11): 

"partnered (partner getting neither pension nor benefit)" has the meaning given by subsection 

OJi; 

25 "partnered (partner getting pension)" has the meaning given by subsection (11): 

"partnered (partner getting pension or benefit)" has the meaning given by subsection (11): 
"partnered (partner in gaol)" has the meaning given by subsection (11): 
"respite care couple" has the meaning given by subsection (8). 

30 Member of a couple-general 

4 (2) Subject to subsection (3). a person is a member of a couple for the purposes of this Act 

(a) the person is legally married to another person and is not, in the Secretary's opinion 
(formed as mentioned in subsection (3)), living separately and apart from the other person on a 

35 permanent basis: or 

(b) all of the following conditions are met: 

(i) the person with a person of the opposite sex (in this paragraph called the "partner"): 

(ii) the person is not legally married to the partner: 

(iii) the relationship between the person and the partner is. in the Secretary's opinion 
40 (formed as mentioned in subsections (3)). a marriage-like relationship: 
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(iv) both the person and the partner are over the age of consent applicable in the State or 
Territory in which they live: 

(v) the person and the partner are not within a prohibited relationship for the purposes of 
section 23B of the Marriage Act 1 961 . 

5 Note: a prohibited relationship for the purposes of section 23B of the Marriage Act 1961 is a 
relationship between a person and: 
. an ancestor of the person: or 
. a descendant of the person: or 

. a brother or sister of the person (whether of the whole blood or the part-blood). 

10 

Member of a couple-criteria for forming opinion about relationship 

4 (3) In forming an opinion about the relationship between 2 people for the purposes of 
paragraph (2) (a) or subparagraph (2) (b) (iii). the Secretary is to have regard to all the 
circumstances of the relationship including, in particular, the following matters: 
15 (a) the financial aspects of the relationship, including: 

(i) any joint ownership of real estate or other major assets and any joint liabilities: and 

(ii) any significant pooling of financial resources especially in relation to major financial 
commitments: and 

(in) any legal obligations owed by one person in respect of the other person: and 
20 (iv) the basis of any sharing of dav-to-dav household expenses: 

(b) the nature of the household, including: 

(i) any joint responsibility for providing care or support of children: and 

(ii) the living arrangements of the people: and 

(iii) the basis on which responsibility for housework is distributed: 
25 (c) the social aspects of the relationship, including: 

(i) whether the people hold themselves out as married to each other: and 

(ii) the assessment of friends and regular associates of the people about the nature of their 
relationship: and 

(iii) the basis on which the people make plans for, or engage in. ioint social activities: 
30 (d) any sexual relationship between the people: 

(e) the nature of the people's commitment to each other, including: 

(i) the length of the relationship: and 

(ii) the nature of any companionship and emotional support that the people provide to each 
other: and 

35 (iii) whether the people consider that the relationship is likely to continue indefinitely: and 

(iv) whether the people see their relationship as a marriage-like relationship. 

D. Amending Act 1995 No 105 amending Section 14 

SOCIAL SECURITY (NON-BUDGET MEASURES) LEGISLATION AMENDMENT ACT 1995 No. 
40 105 
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of 1995- SECT 14 

Family relationships definitions-couples 



SECT 

14. Section 4 of the Principal Act is amended: 

(a) by inserting in the definition of "member of a couple" in subsection (1 ). "(3AV after "(3V: 

(b) by inserting in paragraph (2)(a) "or indefinite" after "permanent": 

(c) bv omitting from subparagraph (2)(b)(i) "is living" and substituting "has a relationship": 

(d) bv omitting from subparagraph (2)(b)(iii) "subsection (3)" and substituting "subsections (3) 
and (3AV: 

(e) bv inserting after subsection (3): 

"(3A) The Secretary must not form the opinion that the relationship between a person and his 
or her partner is a marriage-like relationship if the person is living separately and apart from the 
partner on a permanent or indefinite basis.". 
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APPENDIX B 
CODING - Document Type definitions (dtds) 

ACT.DTD 

i *********************************************** 

5 Document Type Definition for a set of acts 

Typical invocation: 

<!DOCTYPE acts PUBLIC "-//SGMLSE//DTD 1.0 Acts//EN"> 

Copyright Aunty Abha's Electronic Publishing Ptv. Ltd. 1996, 1997 
********************************************************* ***************************** 

10 <! ENTITY % CQNSOL "IGNORE"> 

<!-- ****** Include common element and entity definitions *******—> 
<! ENTITY % common 

PUBLIC "-//SGMLSE//ELEMENTS 2.0 Common Elements//EN"> 
%common: 

15 <!- ******End common element and entity definitions ********„> 
<! ELEMENT acts -- (title, header?. act+) 
> 

<!ENTITY % act PUBLIC "-//SGMLSE//DTD 1.0 Act//EN"> 
%act; 

20 ACTS.DTD 



************************************************ 



***************************** 



Document Type Definition for a set of acts 
Typical invocation: 

<!DOCTYPE acts PUBLIC "-//SGMLSE//DTD.1 .0 Acts//EN"> 

25 Copyright Auntv Abha's Electronic Publishing Ptv. Ltd. 1996. 1997 

a***************************************************************************** 

<! ENTITY % CQNSOL "IGNORE"> 

<!****** Include common element and entity definitions *****--> 
<!ENTITY % common 
30 PUBLIC "-//SGMLSE//ELEMENTS 2.0 Common Elements//EN"> 

%common: 

<!-- ****** End common element and entity definitions *******—> 

<! ELEMENT acts -- (title, header?, act+) 

> 

35 <! ENTITY % act PUBLIC "-//SGMLSE//DTD 1 .0 Act//EN"> 
%act: 

REG.DTD 



<! 



I __*************************************************************************** 



Document Type Definition for a set of regulations 
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Typical invocation: 

<!DOCTYPE reaact PUBLIC "-//SGMLSE//DTD 1.0 Regulation Act//EN"> 
Copyright Auntv Abha's Electronic Publishing Ptv. Ltd. 1996. 1997 
REVISION History 



**************** 



190197 TH Since RULE. REG and SECTION are all eouivalent removed REG from 
this DTD 

Added long-title 

********************************************************************************** 

10 <!ELEMENT reg - - (title, notes?, provisions?, (preamblellong-title)?. 
((order+l (sectionlschedule)+ lchapter+|part+).schedule*))> 
<!ATTLIST reg Id ID #REQUIRED 

date CDATA #IMPLIED - used in numacts -- 
%status: 
15 %subiect: 



REGS. DTD 



<! 



20 Document Type Definition for a set of regulations 

Typical invocation: 

<!DOCTYPE regs PUBLIC "-//SGMLSE//DTD 1.0 Regulations/ZEN'^ 
Copyright Auntv Abha's Electronic Publishing Ptv. Ltd. 1996. 1997 

25 REVISION History 
*********** 



*************************************************************************** 

<! ENTITY % CONSOL "IGNORE"> 
<!ELEMENT regs -- (title, header?. reo+l> 
30 <!~ ****** include common element and entity definitions *******—> 
<! ENTITY % common 

PUBLIC "-//SGMLSE//ELEMENTS 2.0 Common Elements//EN"> 
%common; 

<!-- ****** End common element and entity definitions ********..> 
35 <! ENTITY % reg PUBLIC "-//SGMLSE//DTD 1.0 Regulation//EN"> 
%reg: 



COMMON. ELT 

^ I ************************************************************************** 
40 Common element, attribute and entity definitions. 
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Typical invocation: 

<! ENTITY % common PUBLIC 

"-//SGMLSE//ELEMENTS 3.0 Common Elements//EN"> 
%common: 

VERSION 319 Jan 1997 

Copyright Auntv Abha's Electronic Publishing Ptv. Ltd. 1996. 1997 

REVISION History 
************* 

141096 TH Added p* to definition of schedule 

151096 TH Added %reoid: %reglbl: attributes to RULE. 

ORDER. DIVISION. SUB-DIVISION 

Added P+ and SUB+ to rule definition 

251096 TH Added ststus entity for amendment information 

291096 TH Changed definition for ORDER 

141196 TH Added <ALTERED> element 

261 196 TH Too many changes to mention - Designated Version 2 

150197 TH Too many changes to mention - 

Designated Version 3 

190197 TH Changed contents of SECTION and SCHEDULE to (title. 

(%unstruct-cont:)) 

TH Since RULE. REG and SECTION are all eouivalent, renamed all to 

SECTION and added attribute TYPE to designate which type of section thev are 

TH Added entity SUBJECT to allow each element to belong to 1 or 

more subjects 

TH Added entity CONSOL which is invoked in the consolidation DTD 

using marked sections 

************************************************************************ 
<!— 



+++++--> 

<!-- ISO Character Entity Set Declarations and References --> 
<L~ 

+++++ - - > 

<! ENTITY % ISOnum PUBLIC "ISO 8879:1 986//ENTITIES Numeric and 

Special Graphic//EN" 
<!ENTITY % ISQpub PUBLIC "ISO 8879:1 986//ENTITIES 
Publishina//EN" 
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<!ENTITY % ISOtech PUBLIC "ISO 8879:1 986//ENTITIES 



10 



General Technical//EN" 

! ENTITY % ISOIatl PUBLIC "ISO 8879:1986//ENTITIES 



Added Latin 1//EN" 

<!ENTITY % ISQqrk3 PUBLIC "ISO 8879:1 986//ENTITIES 

Greek Svmbols//EN" 

%ISOnum: 
%ISQpub: 
%ISOtech; 
%ISOIat1 ; 
% ISQqrk3: 

<!_. ******************** End character entities **** 



**************** 



— > 



******************** pQpQppg^gp Entities ******************** _ > 



15 



20 



<!ENTITY%consol ""> 
<!f %CONSOL f 
<!ENTITY%consol "cai 



NAMES 



#IMPLIED 



-- Creating amending act ID (IDs) - 



eai NAMES 



#IMPLIED 



— Ending amending act ID (IDs) - 



25 



> 

U> 

<! ENTITY % status 



"insert-date NUMBER #IMPLIED -- insert date - 



insert-leg IDREF 



#IMPLIED -- link to the inserting legislation - 



30 



repeal-date NUMBER #IMPLIED -- repeal date - 



repeal-leg IDREF 



#IMPLIED -- link to the repealing legislation - 



amend-date NUMBER #IMPLIED - amended date - 



amend-leg IDREF 



#IMPLIED - link to the amending legislation - 



35 



<! ENTITY % reqid "id ID #REQUIRED" 
- required id - 



<!ENTITY % reglbl "Ibl CDATA #REQUIRED" 
- required label -- 

> 

40 <!ENTITY%emph"bold I ital" 
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-- emphasised text -- 

> 

<! ENTITY % refs "xref I rngref | tempref I noteref" 

-- references - 

5 > 

<!ENTITY % inline "quote [ ilean | %emph; | %refs: | super I subscr" 

-- inline text elements - 

> 

<! ENTITY % text "#PCDATA | %inline:" 
10 -- inline text elements plus character data -- 

> 

<! ENTITY % ref-cont "#PCDATA" 
- content of references - 

> 

15 <!ENTITY%plevel "p I dpeqn I tblblk I list I blockquote I form" 
-- paragraph level (block) elements - 

> 

<! ENTITY % tblcon "p I dpeqn I list" 

-- content of table cells - 

20 > 

<!ENTITY % para-cont "(%plevel:)+" 

-- content of long-title or section level elements - 

> 

25 <! ENTITY % unstruct-cont "((%plevel;) |article|chapter|part|notes)*"> 

<!ENTITY% subject "subject NAMES #IMPLIED" 

-- optional subject - 

> 

<!-- ************** ^pi(j Parameter Entities ************************ 

<! __ ************** Include Maths and Table elements *********** -> 

<! ENTITY % atimath PUBLIC "-//SGMLSE//ELEMENTS Math Equation 
35 Structures//EN"> 
%atimath; 

<! ENTITY % atitbl PUBLIC "-//SGMLSE//ELEMENTS Table Structures//EN"> 
%atitbl: 

40 
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<!m ******************** End Maths and Tab | e e | em ents ******** -> 



<!-- Main elements --> 

<! ELEMENT part - - (title. (%olevel:)*. (chapter+ldivision+|section+r, notes?) 
> 

<!ATTLIST part %reaid: 
%reqlbl; 

%status; 

% subject: 

%consol: 

> 

<! ELEMENT order - - (title. (divisionlsectionlpartlschedule)+) 
-- in numreqs -- 

> 

<!ATTL1ST order %reaid: 
%reqlbl; 

%status; 

%subiect; 

%consol: 



> 

<!ELEMENT division - - (title, (sub-division+|section+)) 

-- in numreqs 

> 

<!ATTLIST division %regid: 
%realbl: 

%status; 

%subiect: 

%consol: 

> 

<! ELEMENT sub-division -- (title, section+) 

-- in numreqs -- 

> 

<!ATTLIST sub-division %reqid: 

%reqlbl; 
%status: 
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%subiect: 

%consol: 

> 

5 <! ELEMENT chapter - - (title. (%plevel:)*. (part+lsection+larticle+)?) 
— part+ and section+ for numacts - 

> 

<!ATTLIST chapter %reaid: 
%realbl: 

10 %status; 

%subiect: 

%consol: 

> 

15 <!ELEMENT article - - (title. (%pleveir, notes?) 
> 

<!ATTLIST article %reaid: 
%realbl: 

%status: 

20 %subiect: 

> 

<! ELEMENT section - - (title. (%unstruct-cont:))> 

<!ATTLIST section 
25 %reqid: 

%realbl: 

%status: 

astprov NAMES #IMPLIED 

type (section I rule I reo) section 

30 %subiect: 

%consol; 

> 

<! ELEMENT schedule - - (title?. (%unstruct-cont:)) 

35 - Schedule of an Act - 

> 

<!ATTLIST schedule %reqid: 
%reglbl: 

%status; 

40 %subiect; 
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%consol: 



> 



5 

<! ELEMENT provisions - - (title. tblblk+) 

-- provisions - 

> 

<!ATTLIST provisions 
10 %subiect: 
> 

<! ELEMENT form - - (title, formreq. front back?)> 
<!ATTLIST form %reqid 
%reqlbl; 
15 %status; 

parastvle CDATA #IMPLIED 

%subiect; 

> 

20 <! ELEMENT formreq - - (#PCDATA) 
-- Regulation - 
> 

<!ATTLIST formreo 

%subiect: 

25 > 

<! ELEMENT front - - (asis) 

-- front of form - 

> 

<!ATTLIST front 
30 %subiect: 

> 

<!ELEMENT back - - (asis) 

-- back of form - 

> 

35 <!ATTLIST back 

%subiect: 

> 

<! ELEMENT asis - - (#PCDATA) 



64 



"text as is - 
> 

<!ATTLIST asis 

%subiect: 

5 > 

<!- ************** Header elements ********************* _.> 
<! ELEMENT header - - (scope?. updated?)> 
<!ATTLIST header 
%subiect; 

10 > 

<!ELEMENT scope - ■ (%text;)+> 

<!ATTLIST scope 

%subiect; 

15 > 

<! ELEMENT updated - - (%text;)+> 
<!ATTLIST updated 

%subiect: 

20 > 

<! ELEMENT notes - o (note+)> 
<!ATTLIST notes 

%subiect: 

> 

25 <!ELEMENT note - - (%plevel:)+ 

> 

<!ATTLIST note id ID #REQUIRED 

%subiect: 

> 

30 <!- ****************** End Header elements ****************._> 
******************* gfpuQiypgj sl^rnents ***************** 



<!ELEMENT title - - (%text:)+ 

35 -- Generic title - 

> 

<! ._ End structura | elements *************** --> 
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<! ELEMENT blockquote - - (%unstruct-cont:)+ 
> 

<!ATTLIST blockquote parastvle CDATA #IMPLIED 
5 %subiect: 
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<! ELEMENT p - - (%text:)+ 

- paragraph - a line of text terminated by a carriage return in the hardcopy 

> 

<!ATTL1ST p parastvle CDATA #IMPLIED 

%subiect: 

> 

<!ELEMENT list- - (\\)+ 

> 

<!ATTLIST list parastvle CDATA #IMPLIED 
%subiect; 



<!ELEMENTIi - (p I blockquote I tblblk I list)+ 

20 -- item in a list — 

> 

<!ATTLIST li Ibl CDATA #REQUIRED 



15 



%status; 



%subiect: 



25 > 

<! ELEMENT tblblk - - (title?. (table|#PCDATA)) 
-- table block -- 

> 

<!ATTLIST tblblk parastvle CDATA #IMPLIED 

30 %subiect: 

> 

<! ELEMENT dpeqn - - (fd) 

-- display equation -- 

> 

35 <!ATTLIST dpeqn parastvle CDATA #IMPLIED> 



<j-- ****************** gp(j p|Q^Q| GlgrnGnts ****************** > 



^ I ******************* jpijpg elements *********************** 
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<! ELEMENT xref - - (%ref-cont:)+ 

cross reference to a single target point - 

> 

<!ATTL1ST xref ref IDREF #REQUIRED 

5 > 

<! ELEMENT noteref - 0 EMPTY 
- cross reference to a note - 

> 

<!ATTLIST noteref ref IDREF #REQUIRED 

10 > 

<! ELEMENT rngref - - (%ref-cont:)+ 

-- cross reference to a seguential range of target points - 

> 

<!ATTLIST rngref startref NAME #REQUIRED 

15 enclref NAME #REQUIRED 

> 

<!ELEMENT tempref - - (%ref-cont;)+ 

- cross reference to a single target point where the idstring is unknown - 

> 

20 <! ELEMENT ilegn - - (f) 

-- inline eguation - 

> 

<!ELEMENT super - - (%text:)+ -(super.subscr) 
-- superscript - 

25 > 

<! ELEMENT subscr - - (%text:)+ -(super.subscr) 

-subscript - 

> 

<!ELEMENT guote - - (%text:)+ 
30 > 

<! ELEMENT bold - - (%text;H -(bold) 

-- text set in bold which is not a title or a label - 

> 

<!ELEMENT ital - - (%text:)+ -fitah 

35 - text set in italic which is not a title or a label - 

> 

<! ELEMENT altered - 0 EMPTY> 
<!ATTLIST altered by CDATA #REQUIRED> 

****************** ^p|^ inline elements ******************* > 
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<!ELEMENT long-title - - (%para-cont:)> 
<!ELEMENT preamble - - (%para-cont:)> 



/. CONSOL.DTD 

********************************************************* 

Document Type Definition for the consolidation 
Typical invocation: 

<!DOCTYPE consol PUBLIC "-//SGMLSE//DTD 1.0 
Colsolidation//EN"> 

Copyright Aunty Abha's Electronic Publishing Ptv. Ltd. 1996, 1997 

REVISION History 
************ 

********************************************************* 

<! ENTITY % CONSOL "INCLUDE"> 

<!-- ****** End common element and entity definitions *********** ~> 

<!ELEMENT consol - - (actlreo)+ 

> 

<!-- ****** Include common element and entity definitions ********* ~> 
<! ENTITY % common 

20 PUBLIC "-//SGMLSE//ELEMENTS 2.0 Common Elements//EN"> %common; 

<! ENTITY % reo PUBLIC "-//SG MLS E//DT D 1.0 Regulation//EN"> %reo: 
<!ENTITY % act PUBLIC "-//SGMLSE//DTD 1 .0 Act//EN"> 
%act: 



10 



15 
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TABLE OF CONTENTS 

5 

Database Tables Entry Procedure 

fAI GENERAL 

10 FA 011 Introduction 

f A 021 General Purpose and Structure of the DatabaseX 

TA 031 General Note about Dates Required for Fields in Database Tables 

FBI MASTER TABLE 

15 

rB 011ID FIELD 

IB 021 Date of Assent/Date of Notification Field 
IB 031 Short Title Field 
IB 041 Date of Commencement Field 
20 rB 04.11 Other forms of commencement or notification 
fB 051 Date of Expiry Field 
fB 061Type Field 
TB 071 Reprint No Field 
FB 081 Reprint Date Field 

25 

TCI TEXTBLOCK TABLE 

fC 011 When the should it be used? 
fC 021 ID Field 
30 fC 031Textblock ID1 
fC 041Textblock ID2 
fC 051 Date of Commencement Field 
TC 061 Date of Expiry Field 



69 



COMMONWEALTH PROJECT 

CHAPTER XX - Database Tables Entry Procedure 
fAl GENERAL 

5 \A 011 Introduction 

• This Chapter is divided into three topics: 
fAl This General topic. 

TBI The Master Table of the Data Base: and 
TCI The Textblock Table of the Data Base. 
10 • All text like this in 1Qpt Arial font size is "explanatory text and notes" on the 

data base. 

• All text in Courier 9pt font size with a rule on the left hand side is the text used 
for examples, the text is taken from the Commonwealth data where possible to make it 
look like the real thing, however, some examples have been created for the purposes 

15 of explanation and do not exist in the data itself. 

• References in capitals to ACT(S) or REGULATION(S) are references to the 
whole Acts or Regulations. The word regulation when written with a lower case "r" will 
refer to a numbered regulation (eg: regulation 2). Note: this does not apply to the text 
of examples which have been left as thev appear in the data. 

20 • The word Section written with a capital "S" will refer to the numbered section 

of an ACT (eg: Section 2). Note: this does not apply to the text of examples which 
have been left as thev appear in the data. 

• The word Part written with a capital "P" will refer to the means of dividing an 
ACT known as a Part (eg: Part 2 or Part II). Note: this does not apply to the text of 

25 examples which have been left as thev appear in the data. 

• Note: the reference to Sections in Commonwealth ACTS and regulations in 
Commonwealth REGULATIONS is bv way of the lowest piece of text first, eo: 8(8)(a) 
would be written "paragraph 8(8)(aV not "Section 8(8)(aY'. 

30 Note: Fields are out of database structure order in the examples because thev appear 
at different places in the legislation to the structure used in the database tables. 

f A 021 General Purpose and Structure of the Database 

Purpose 

35 To provide a means of managing, monitoring and checking the content of the 
Commonwealth Legislation Consolidation. 

To allow the time based (versioning) capacity of the DTD and SGML coding being 
under taken to be realised. 
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Basic Structure 

The database is to consist of two tables. 
These Tables will be known as MASTER and TEXTBLOCK. 
5 The specific purpose of each Table will be as follows:- 

MASTER will focus on fields that collect data about an ACT or REGULATION as a 
whole. 

TEXTBLOCK will focus on specific sub-elements of the whole of an ACT or 
REGULATION. 

10 

TA 031 General Note about Pates Required for Fields in Database Tables 

Dates in the Database will be used primarily to identify two things: 

• the beginning of a whole or part of an ACT or REGULATION, or 

• the end of the whole or part of an ACT or REGULATION 

15 

Entries for dates will all be in the dd/mm/w formula. 
There are 3 ways dates will be appear in the legislation: 

• specific - are stated in the legislation itself (for example. Date of Assent) 
20 • to be advised - are to be published or advised elsewhere (for example. 

proclaimed in Gazette) 

• conditional - are based on something else happening (for example, the 
commencement of another ACT or REGULATION, the creation of or termination of an 
organisation, the happening of an event) 

25 

TBI MASTER TABLE 
IB 011 ID FIELD 

This is the most important field in the database as it ties all the remaining fields and 
30 their information together. 

For the example used here, that is. the Social Security Act this will be Act-19910046. 
This is arrived at by combining, 

35 (i) the type of legislation, in this case an ACT - see (a) below, then 

(ii) the year of enactment/creaWon. in this case 1991 - see (b) below, and finally, 

(iii) the ACT'S Number- see (c) below. 
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All three parts of the ID are important. Inputting the right type, that is. Act for ACTS 
and Reg for REGULATION etc.. and the right year and number is critical as only the 
correct combination of all three will give the reouired accuracy. 



5 In the ID field the year and number are separated bv a hyphen. Also four digits must 
be used for the year number, thus 0046 and not 46 is used for the ACT'S number in 
this example. 

An important point to note is that it is possible for an ACT or REGULATION to be 
10 known as say the Federal Law Act 1996 but to be Act No 2 of 1997. so that its ID then 
will be Act-1 9970002 

$$# 

15 $$T 

SOCIAL SECURITY (a) ACT 1991 
- Updated as at 10 July 1995 

MI 

20 *1* The Social Security Act 1991 as shown in this reprint comprises Act No. (c)46. 
(b)1 99! amended as indicated in the Tables below.< 



25 



30 



35 



fB 021 Date of Assent/Date of Notification Field 

This will appear in different places according to the style and type of information. 

For ACTS use the Table of Acts at the column Date of Assent. The entry for Act No 
46. 1991 being the entry for the principal ACT, that is the Social Security Act, is the 
place to look and the second column shows the date of assent as 23 Apr. 1 991 (see 
(d) below). 

Table of Acts< 

Act Date Date of Application< 

Number and of assent commencement saving or< 

year transitional< 

provistons< 

Social Security Act I991< 

46.1991 (d)23 Apr 1991 1 July 1 991 < 
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For REGULATIONS use the Table of Statutory Rules at the column Date of 
Notification. 

The entry for REGULATION No 36. 1990 being the entry for the principal 
5 REGULATIONS, that is the Cash Transactions Reports Regulations, is the place to 
look and the second column shows the date of notification as 27 Feb 1990 (see (e) 
below). 

*!* The Cash Transaction Reports Regulations (in force under the Cash Transaction Reports 
10 Act 1988) as sho wn in this reprint comprise Statutory Rules 1990 No. 36 amended as indicated 
in the Tables below. 

Table of Statutory Rules 

Year and Date of Date of Application, 

Number notification commencement saving or 

15 in Gazette transitional 

provisions 

1990 No. 36 (e)27 Feb 1990 27 Feb 1990 

f B 031 Short Title Field 

20 This usually appears in Section 1 of an ACT or regulation 1 of a REGULATION. This 
is the best place to take the name from as it is the legislated/official way that the ACT. 
REGULATION etc.. is to be referred to etc. See (f) below. 

The name should be entered in full (no abbreviations). 
25 You should include the year even though it is part of the ID and also the words ACT or 
REGULATION. This will firstly, provide a cross check as normally these should match. 
It will also indicate those ACTS or REGULATIONS where the Short Title Year is 
different to the Year and Number in the ID field. 

30 $$A 
$$T 

SOCIAL SECURITY ACT 1991 - SECT 1< 
Short title 

35 $$T 

$$NSECT 

I . This Act may be cited as the (f) Social Security Act 199 1 . * 1 * $$S 
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TB 041 Date of Commencement Field 

This information usually appears in Section 2 for an ACT and regulation 2 for a 



REGULATION. 



5 This is the best place to take the date of commencement from as here it is part of the 
leaislation/the law and therefore always correct (even if its wrong). If taken from the 
Table of Acts or Table of Regulations an error would not be correct even if not made 
bv us because technically: Tables. Title Pages and even side/margin notes are not 
considered part of legislation. 

10 

See (g) below \ox an example. 

$$T 

SOCIAL SECURITY ACT 1991 - SECT 2< 
15 Commencement 

$$T 

SSNSECT 

20 2. This Act commences on (g) 1 July 1991. 
$$A 
$$T 

IB 04.11 Other forms of commencement or notification 

25 The example given at (q) above is a simple form of commencement in that one date is 
stated in Section 2. 

There are other forms of commencement as follows:- 

24. ACTS or REGULATIONS where no date of commencement is specified 
enacted on or before 31/12/1937 (that is. there is no Section 2 and no other section 

30 dealing with commencement) commence on the day on which the ACT was assented 
to for ACTS (for example, the Acts interpretation Act 1901 assented to on 12/7/1901). 
These Acts reouire no entry in the MASTER TABLE as the Date of Commencement 
and Pate of Assent are the same. 

25. ACTS or REGULATIONS where no date of commencement is specified 

35 enacted on or after 1/1/1938 (that is. there is no Section 2 and no other section dealing 
with commencement) then the Act bv default commences on 28th day after the Date of 
Assent. These Acts do reguire an entry in the MASTER TABLE as the Date of 
Commencement and Date of Assent are not the same. 
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26. ACTS or REGULATIONS where various Parts, Sections, regulations etc.. 
commence on different dates or on dates to be proclaimed or notified in Gazette. 

27. ACTS or REGULATIONS where various Parts. Sections, regulations etc.. 
commence the commencement of another ACT. REGULATION or Part or Section of 

5 another ACT or REGULATION etc. 

Note: With respect to the calculation of time (as for example, in the case of 
commencement 28 days after assent) Section 36 of the Acts Interpretation Act affects 
how this is done. Section 36 provides: 
10 28. Where in an ACT any period of time, dating from a given day, act, or event, is 
prescribed or allowed for any purpose, the time shall, unless the contrary intention 
appears, be reckoned exclusive of such day or of the day of such act or event. 

29. Where the last day of any period prescribed or allowed by an ACT for the 
15 doing of anything falls on a Saturday, on a Sunday or on a day which is a public 

holiday or a bank holiday in the place in which the thing is to be or may be done, the 
thing may be done on the first day following which is not a Saturday, a Sunday or a 
public holiday or bank holiday in that place. 

20 The above will be handled in Australia with respect ot those ACTS or REGULATIONS 
to which this applies. 

\B 051 Date of Expiry Field 

This is the opposite of commencement: that is. it indicates when the whole of an ACT 
25 or REGULATION or some Part. Section or regulation in an ACT or REGULATION 
ceases to have effect. 

Note: because the expiry is provided for in the ACT or REGULATION itself, this is 
different to a repeal. The effect is however, the same. 
30 Sections or Regulations relevant to this field are headed "Sunset clause" or "Sunset 
provision" see (h) below. 

Note: the use of the words "unless sooner repealed" in the examples below. This 
means entries will need to be checked or reviewed to ensure that ACT or 
35 REGULATION has not been sooner repealed. 
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The date or timing of expiry is indicated/expressed in a few different wavs:bv a specific 

date, see (i) below. 

bv a period of years, see (\) below. 

5 30. Examples of expiry of the whole ACT bv a specific date. 

AUSTRALIAN MEAT AND LIVE-STOGK (QUOTAS) ACT 1990 - Updated as at 18 July 
1995 



10 SECT 9 

Sunset clause (h) 

9. This Act, unless sooner repealed, shall cease to be in force at the (i)end of 30 June 1998. 

Note: the example above uses the words "cease to be in force" and the one below the 
15 words "ceases to have effect". The result is still the same for our purpose. 

MEAT AND LIVE -STOCK INDUSTRY ACT 1995 No. 67 of 1995 - 
Assented to 30 June 1 995 



20 SECT 227 

Sunset clause 

227. This Act, unless sooner repealed, ceases to have effect at the end of 30 June 1998. 

31. Example of expiry of Part. Division, Subdivision or Section of ACT after a 
25 specified period of years. 

NATIVE TITLE ACT 1 993 
Updated as at 30 June 1995 

30 SECT 207 

Sunset provision 

207. This Part ceases to be in force at the (j)end of 5 years after the Parliamentary Joint 
Committee is first appointed. 

35 32. Examples of expiry of a portion of a REGULATION 
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FEDERAL COURT RULES 



Updated as at 22 March 1996 



ORDER 75 NATIVE TITLE RULES 
5 NATIVE TITLE ACT 1993 



ORDER 75 
RULE 2 1 
Sunset provision 
10 2 1 . Order 75 ceases to be in force on 1 March 1997. 

MIGRATION (1993) REGULATIONS - Updated as at 25 July 1994 



REG 2A 
15 JOA 

Sunset provision 

2A.10A. No application may be made under this Division on or after 1 July 1993. 
\B 061 Type Field 

20 This Field provides more specific information about the type of legislation. It is 

different to the ID Field described above which gives the legislation a unique ID. This 
Field uses three single character codes to describe the legislation. 
These are as follows: 

25 P = Principal ACTS or REGULATIONS. 

It indicates that this is the main or Principal ACT or REGULATION. 

OR In other words the ACT or REGULATION which gets amended. 

Principal ACTS or REGULATIONS can be either in existence (enacted in previous 

years) or newly enacted (created in the current year). 

30 

There is nothing specifically unigue or different in a principal ACT or REGULATION 
that makes it easy to identify. By elimination it is however, possible to say what is not 
a Principal ACT or REGULATION. This is done by looking at the ACT or 
REGULATION'S title information. Amending Acts or Regulations (which are dealt with 
35 next) usually contain the word's "Amending". "Amendment". "Repeal" or "Statute Law 
Revision" in their Short Title. Another indicator in the case of ACTS is that the Long 
Title will also contain the word's "Amending". "Amendment". "Repeal" or "Statute Law 
Revision" (REGULATIONS however, do not have a Long Title). 
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The example marked (K) and (J) below shows the Long and Short Titles for a Principal 
Act known as the Trade Practices Act. (Compare these examples with the ones 
marked (L) and 20 (M) below). 

5 

LONG TITLE(K) 

An Act relating to certain Trade Practices 
PART I-PRELIMINARY 

10 

SECT 1 
Short titlef.I) 

1 . This Act may be cited as the Trade Practices Act 1974.*!* 
SEE NOTES TO FIRST ARTICLE OF THIS CHAPTER . 

15 

Note: A principal ACT or REGULATION can contain amendments to other ACTS or 
REGULATIONS. It therefore, still needs to be considered for its effect on other ACTS. 
A = Amending ACTS or REGULATIONS. 

It indicates that this is a changing or Amending ACT or REGULATION. 
20 OR In other words the ACT or REGULATION which does the amending. 

Amending ACTS or REGULATIONS will not generally exist in their own right in the 
consolidated information for which we are creating the data base. The changes they 
effect will nearly always become part of the Principal ACT or REGULATION. 
25 There are some rare exceptions to the above point however, which will need to be 
identified (the way to do this most effectively will be to identify them in Australia and 
provide a list or table of what these ACTS and REGULATIONS are). 

As already stated the best ways to identify an Amending ACT or 
30 REGULATION are: 

Amending ACTS or REGULATIONS will nearly always contain the word's "Amending". 
"Amendment", "Repeal" or "Statute Law Revision" in their Short Title. 
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For Acts (but not Regulations) there is also a Long Title at the very beginning of the 
Act (usually before Section 1) which will also contain the word's "Amending" 
"Amendment". "Repeal" or "Statute Law Revision". 

5 The example marked (L) and (M) below shows the Long and Short Titles for the 

Amending ACT known as the Trade Practices (Secondary Boycotts) Amendment Act 
1979. 

LONG TITLE(L) 

10 An Act to amend the Trade Practices Act 1974 with respect Secondary Boycotts and other 
industrial practices. 

PART I-PRELIMINARY 

15 SECT 1 

Short title(M) 

1 . This Act may be cited as the Trade Practices (Secondary Boycotts) Amendment Act 
1979.*!* 

SEE NOTES TO FIRST ARTICLE OF THIS CHAPTER . 

20 

Note: An Amending ACT or REGULATION can be amended itself by a further 
amending ACT or REGULATION. 

More Examples of Amending ACTS and REGULATIONS 
25 Following are some more examples of Amending ACTS and REGULATIONS and what 
to look for. 

Statute Law Revision Acts 

Below are two examples of these. Usually, this is clean up legislation which makes 
30 many changes and often effects a larger number of ACTS. They can be specific as in 
the case of the Decimal Currency example or they can be general as in the case of the 
1 973 example. 

They can both change (amend Parts, Divisions and Sections of ACTS and 
REGULATIONS) and/or delete (repeal) whole ACTS and REGULATION or Parts. 
35 Divisions and Sections. 

Statute Law Revision (Decimal Currency) Act 1966 
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Statute Law Revision Act 1973 

There are other form of Amending ACT similar to the Statute Law Revision Acts as 
follows: 

5 

A.CT. Self-Government (Consequential Provisions) Regulations 1989 No. 3 
Defence Legislation Amendment Act 1984 
Fringe Benefits Tax (Miscellaneous Provisions) Act 1986 
Statute Law (Miscellaneous Provisions) Act (No. 1) 1986 
10 Taxation Laws Amendment Act (No. 3) 1986 

The above can usually be spotted by the use of words such as "Consequential 
Provisions" "Laws Amendment". "Legislation Amendment", "Miscellaneous 
Provisions" in their Short Titles. 

15 

Repeal Acts 

Below are two examples of these. One where the term Legislation is used in the title 
indicating that more many ACTS are being repealed. Again this is often clean up 
legislation which repeals many ACTS whose purpose or reason for being has lapsed. 
20 Alternatively, as the second example indicates Repeal ACTS can be specific, effecting 
the repeal of only one ACT. 

Egg Export Legislation Repeal Act 1984 
National Welfare Fund Repeal Act 

25 

N = Not known 

Indicates that the type of the ACT or REGULATION is not known or cannot be 
determined. These records will the be handled in Australia. 

30 FB 071 Reprint No Field 

The information reouired for this field does not appear in the Commonwealth Data as 
presently supplied to/held bv us. It will need initially to be obtained in the form of a list 
of existing reprints and their numbers and be added to both the Commonwealth data 
and the data base as a once only job. It will then need to be maintained on a monthly 
35 basis using the two AGPS Pamphlet Publications known as ACTS TABLES for Acts 

and STATUTORY RULES TABLES for Regulations, the last page in each contains this 
information for the current year. Note: where the Pamphlets are not available or the 
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reprint number is not known or unavailable then the number 999 should be used to 



indicate this. 



Each of the two tables from the Pamphlets contains the name of the Reprinted ACT or 
5 REGULATION in alphabetical order (but see Statutory Rules example below) followed 
by the date of reprint, then followed bv the words "Reprint No." and a number. It is this 
last number that needs to be entered. 

ACTS TABLE entry example 

10 

National Health Act 1935 (20 September 1996) Reprint No. 5 
STATUTORY RULES TABLE entry example 

Note: Statutory Rules are listed bv their parent Act (the Act under which the are made 
15 appearing in Italic as shown in the example below). 

Banks (Shareholdings) Act 1972- 

Banks (Shareholdings) Regulations (2 August 1995) Reprint No. 2 

20 fB 081 Reprint Date Field 

Like the Reprint Number discussed in TB 071 above the information reguired for this 
field does not appear in the Commonwealth Data as presently supplied to/held bv us. 
It too will need initially to be obtained in the form of a list of existing reprints and be 
added to both the Commonwealth data and the data base as a once only job. It will 
25 then need to be maintained on a monthly basis using the two AG PS Pamphlet 

Publications known as ACTS TABLES for ACTS and STATUTORY RULES TABLES 
for Regulations, the last page in each contains this information for the current year. 

Each of the two tables contains the name of the Reprinted ACT or REGULATION in 
30 alphabetical order (but see Statutory Rules example below) followed bv the date of 
reprint, then followed bvthe words "Reprint No." and a number. 

For this field it is the Date preceding the Reprint Number that needs to be entered. 
For examples see the examples at fB 071 above. 

35 
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Note: Again where the Pamphlets are not available or the reprint date is not known or 



unavailable then the date 00/00/00 should be used to indicate this 



TCI TEXTBLOCK TABLE 

5 

rC 011 When the should it be used? 

TEXTBLOCK entries will not normally be required for ACTS or REGULATIONS which 
are either Principal or Reprinted ACTS or REGULATIONS. But note that in the case 
of Principal ACTS there are exceptions, namely: where the Principal ACT or 
10 REGULATION also amends or repeals other ACTS or REGULATIONS. 

TC 021 ID FIELD 

This field simply repeats the information obtained in \B 011 above. Its purpose is to 
link this Table with the MASTER TABLE by way of the same ID. For the example, in 
15 fB 011 for the Social Security Act the ID was Act-1 991 0046. This ID would be 
repeated in this field. 

TC 031Textblock ID1 

This field is for the ID of the specific Part. Section or regulation in an Amending ACT or 
20 REGULATION that causes a change (amendment) to happen. 

Textblock ID2 (see TC 041 below) on the other hand records the ID of the specific Part. 
Section or regulation in an Amending Act or Regulation that is changed (amended). 

25 EXAMPLE 1 

Following is an example of an amendment to the Social Security Act which shows how 
the information reguired for this field is obtained. 

Please note there are several ways in which Amending ACTS and REGULATIONS are 
30 presented. However, the information reguired for this ID field is present in all cases. 
This first example shows the things to look for and the next example show some of the 
variations possible. 

(N) The first thing reguired is an indication as to type. The example is an Amending 
35 Act. 
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(O) The second thing required is the relevant year. In the example this is 1 995. 
(P) The third thing required is the Act or Reg Number. In this example this is 104. 
(Q) The fourth thing required is the specific Part, Section or regulation doing the 
amending. In this example this is SCH1 (ie: Schedule 1). 

5 

The ID entry for this example would then be as follows: 
ACT-1 99501 04-SCH-1 

SOCIAL SECURITY LEGISLATION (N)AMENDMENT ACT (No. 1HOH995 No. 
10 (P)1 04 of 1 995 



(Q)SCHEDULE 1 Section 4< 

AMENDMENT OF THE SOCIAL SECURITY ACT 1991 RELATING TO< 

THE DEFINITION OF iNCOME< 

15 1. After Paragraph 8 T8) (zf) :< 
Insert:< 

"(zfa) a payment of financial supplement made to the person< 
under the Student Financial Supplement Scheme;".< 

20 EXAMPLE 2 

This example shows a different style of amendment to Example 1 . 

The ID entry for this example would be as follows: ACT-1 99501 05-SEC-4 

It would be made up of the following: 
25 (R) Indication of Amending Act. (This would be Reg if we were dealing with a 
Regulation). 

(S) Year of Act is 1995. 

(T) Act or Rea Number is 105. 

(U) Specific Part. Section or regulation doing the amending is SEC4. Note: there is 
30 no reference to a Schedule (SCH) because Section 4 is doing the amending. 

SOCIAL SECURITY (NON-BUDGET MEASURES) LEGISLATION (R)AMENDMENT 
ACT (S)l995 No. (T)105 of 1995 

35 $$NSECT 

(U)4. Section 1 98 of the Principal Act is amended by inserting after subsection (1 A) : 
$$P 
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< 

"( 1 B) Subject to subsection ( 1 C\ if:< 

(a) a person; (the 'carer' 1 ) is personally providing constant care for a severely 

handicapped person; and< 

5 (b) the handicapped person is temporarily absent from Australia for a period of not 

more than 3 months; and< 

(c) the carer accompanies the handicapped person on his or her absence from 

Australian 

the carer does not cease to be qualified for a carer pension merely because of that absence from 
10 Australia. 
$$P 
< 

"(1C) If, during a calendar year, the carer has accompanied the handicapped person 

outside Australia on more than one occasion, the caser ceases to be qualified for carer pension 
15 under subsection (IB) in that calendar year after he or she has, during that calendar year, 

qualified for carer pension under that subsection for periods that together add up to 3 months.". 
$$A 

TC 041 Textblock102 

20 This field is for the ID of the specific Part, Section or regulation in an Amending ACT or 
REGULATION that is changed (amended). 

Textblock ID1 (see TC 031 above) on the other hand records the ID of the specific Part. 
Section or regulation in an Amending ACT or REGULATION that causes a change 
25 (amendment) to happen. 
EXAMPLE 1 

Following is an example of an amendment to the Social Security Act which shows how 
the information reguired for this field is obtained. 

30 Please note, as with Textblock ID1 . there are several ways in which Amending ACTS 
and REGULATIONS are presented. However, the information reguired for this ID field 
is present in all cases. This first example shows the things to look for and the next 
example shows some of the variations possible. 

(V) Again the first thing is an indication as to type. The example is an Amending 
35 Act. 

(W) The second thing reguired is the relevant year. In the example this is 1 991 . 
IX) The third thing reguired is the Act or Reg Number. In this example this is 46. 
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(Y) The fourth thing required is the specific Part. Section or Regulation that is being 
amended. In this example this is SEC8. 



The ID entry for this example would then be as follows: 
5 ACT-1 991 0046-SEC-8 

SOCIAL SECURITY LEGISLATION AMENDMENT ACT (No. h 1995 No. 104 of 1995 - 



SCHEDULE l Section 4< 

10 AMENDMENT OF THE SOCIAL SECURITY (V)ACT (W)1991 

(X) Tlf not available/reproduced in the Amendment text can be obtained from 
the main ID field in 
MASTER TABLET 

RELATING TO< 

15 THE DEFINITION OF INCOME< 

1 . After Paragraph (Y)8 (8) (zf) : 
Insert: < 

"(zfa) a payment of financial supplement made to the person 
20 under the Student Financial Supplement Scheme;". < 
EXAMPLE 2 

This example shows a different style of amendment to Example 1 . 

The ID entry for this example would be as follows: ACT-1 99501 05-SEC-1 98 

25 It would be made up of the following: 

(Z) Indication of Amending ACT. (This would be Reg if we were dealing with a 

REGULATION). 

(AA) Year of ACT is 1991. 

(BB) The third thing reguired is the ACT or REGULATION Number. In this example 
30 this is 46. 

(CO Specific Part. Section or regulation being amended is SEC 198. 

SOCIAL SECURITY (NON-BUDGET MEASURES) LEGISLATION AMENDMENT ACT 
1995 No. 105 of 1995 

35 (Z) (A A) (BB) fif not available/reproduced in the Amendment text can be obtained from 
the main ID field in MASTER TABLE1 
$$NSECT 
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4. Section (CQ198 of the Principal Act is amended by inserting after subsection (1 A) : 

$$P 

< 

"(IB) Subject to subsection ( 1 C\ if:< 

5 (a) a person (the 'carer') is personally providing constant care for a severely 

handicapped person; and < 

(b) the handicapped person is temporarily absent from Australia for a period of not 

more than 3 months; and< 

(c) the carer accompanies the handicapped person on his or her absence from 

10 Australian 

the carer does not cease to be qualified for a carer pension merely because of that absence from 

Australia. 

$$P 

< 

15 "( 1C) If, during a calendar yean the carer has accompanied the handicapped person 

outside Australia on more than one occasion, the carer ceases to be qualified for carer pension 
under subsection (IB) in that calendar year after he or she has, during that calendar year, 
qualified for carer pension under that subsection for periods that together add up to 3 months. 
$$A 

20 

fC 051 Date of Commencement Field 

This field is for the date an amendment or repeal of a specific Part. Section or 
regulation commenced. See also fB 041 for information on commencement. 

25 EXAMPLE 

Below is an example of a commencement provision from an amending ACT. Note 
how various sections of the amending ACT are allocated a date of commencement. 
Using the Section identified in TEXTBLOCK ID1 the date of commencement can be 
identified and entered in this field. 

30 

Thus if the TEXTBLOCK IDI field were ACT-1 99501 05-SEC-8 then the date 
information reouired for this field would be 1 July 1 995. See (DP) below. 

SOCIAL SECURITY (NON-BUDGET MEASURES) LEGISLATION AMENDMENT ACT 
35 1 995 No. 1 05 of 1 995 - SECT 2< 
Commencement 
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$$T 



$$NSECT 

2. (1) Subject to this section, this Act commences on the day on which it receives the 

5 Royal Assent. 
$$P 
< 

(2) Subdivision A of Division 2 of Part 2 is taken to have commenced on 1 July 1993. 

$$P 
10 < 

(3) Section 8 and 9 are taken to have commenced on (DD)1 July 1995. 

$$P 
< 

(4) Section 10 is taken to have commenced on 1 April 1993. 

15 $$P 

TC 061 Date of Expiry Field 

This field provides for amendments that are enacted for a period of time, for example; 
during a special event such as the Olympics. 

20 

Note: Expiry provisions are rare and should only be added if clearly specified in the 
data as in the example below. 

EXAMPLE 
25 See (EE) below. 

OLYMPIC SECURITY (NON-BUDGET MEASURES) LEGISLATION AMENDMENT 
ACT 1997 No. 109 of 1995 

30 $$NSECT 

4. Section 298 of the Principal Act is amended for the period commencing at midnight 

on 1 July 1997 and ending on midnight (EE)25 July 1997 by inserting after subsection (2A) : 

$$P 

< 

35 "(2B) Subject to subsection (2C) . if:< 

(a) a person (the 'carer') is personality providing constant care for a severely 

handicapped person; and< 
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(b) the handicapped person is temporarily absent from Australia for a period of not 

more than 3 months; and < 

(c) the carer accompanies the handicapped person on his or her absence from 

Australian 

5 the carer does not cease to be qualified for a carer pension merely because of that absence from 
Australia. 
$$P 
< 

"(2C) If, during a calendar year, the carer has accompanied the handicapped person 

10 outside Australia on more than one occasion, the carer ceases to be qualified for carer pension 
under subsection (IB) in that calendar year after he or she has, during that calendar year, 
qualified for carer pension under that subsection for periods that together add up to 3 months. 

$$A 
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APPENDIX D 



Keying Guide for Australian 
Legislation Documents 



General 
Validation 

All files produced must be parsed against the relevant DTD and each table should be viewed using 
a suitable Table renderer to make sure that they have been coded correctly. 

10 DTD modifications 

No local modifications must be made to the supplied DTD's. If there are any situations in which it 
is thought that a change to a DTD is required then the reouested change and the reasons for it 
must be submitted to SGMLSE. If a change is deemed necessary, then the DTD will be changed 
in the UK and resupplied. This is necessary to maintain consistency in the DTD's being used at 

15 both ends in the process. 
Files 

The SGML files that will be supplied have already been partially processed but will be invalid 
according to the DTD (especially the tables). 

Each file should omit the document type declaration and begin directly with the root element. 

20 Carriage return characters 

Carriage return characters must not appear in any element which has #PCDATA within its content 
model. If it is wished to use carriage return characters to shorten line lengths, then they must be 
placed in position's where thev will be ignored bv an SGML parser e.g. in places where #PCDATA 
is not allowed, or within start and end tags in places where separator characters are allowed. 

25 Case 

Element and attribute names are case-insensitive. Thev may be entered in either uppercase, 
lowercase or a mixture. 

Attribute values are usually case-insensitive. The only time that thev are case-sensitive is when 
thev have a declared type of CDATA. in which case the string values should be entered directly as 
30 thev appear in the text. 
Markup minimisation 

No non-empty elements have omissible start or end tags, but the empty end tag </> can be used 
to end the currently open element. A carriage return character can not occur within an empty end 
tag. 

35 DTD structure 

There are four DTDs and a common element declaration that are used to define the structure of 

the legislation. 

REGS.DTD 
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This DTD has the public identifier "-//SGMLSE//DTD 1 .0 Reaulations//EN" and contains the 
declaration for the regulations, it has two parameter entity references which include "- 
//SGMLSE//DTD 1.0 Act//EN" and "-//SGMLSE//DTD 1.0 Reoulation//EN". 
The file reas.sam produced by the Perl script regs.o/ conforms to reqs.dtd and calls in all acts as 
5 parameter entities. 
ACTS-DTD 

This DTD has the public identifier " -//SG MLS E//DT D 1 .0 Acts//EN" and contains the declaration for 
the acts. It has a parameter entity references which includes "-//SGMLSE//DTD 1 .0 Act//EN". 
The file acts.sam produced by the Perl script acts.pl conforms to acts.dtd and calls in all acts as 
10 parameter entities. 
ACT. DTD 

This DTD has the public identifier "-//SGMLSE//DTD 1.0 Act//EN" and contains the declaration of 
an act. 
REG. DTD 

15 This DTD has the public identifier "-//SGMLSE//DTD 1.0 Reaulation//EN" and contains the 
declaration of a regulation. 
COMMON. ELT 

This list of elements has the public identifier "-//SGMLSE//ELEMENTS 1 .0 Common 
Elements//EN" and includes element and entity definitions common to all document types. 
20 Character entities 

The character entities allowed have been selected from the ISO public sets isogrkl , isoork3, 
isolatl. isonum, isopub and isotech. 

These characters are translated one-to-one to the equivalent character in the Times New Roman 
True Type font 

25 The <guote> or <blockauote> elements should be used instead to surround any quoted text. 
Use Quotes (") at the beginning and at the end of these elements. 
Labels and identifiers 

The maior structural elements - act, reo. part, schedule, section, sub, s-sub, ss-sub. 

30 all have a reguired label attribute (Ibl). Unigue identifiers should be generated for these elements. 
The label for these elements is the preceding number or letter WITHOUT any punctuation or 
parentheses. For example: 

1979 No. 141 The charge to income tax - REG 1 
Income Tax 

35 1. Fred ... 

1. (1) This is ... 

<section tvpe="reg" 1 b 1 =" 1" ID-"CWACT- 1 9790 1 4 1 -SEC- 1 "> 

<title>Income Tax</> 

<list> 

40 <li lbl='r><p>Fred ...</> 
<list> 
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insert-leg 


IDREF 


#IMPLIED 




repeal-date 


NUMBER 


#IMPLIED 




repeal-lee 


IDREF 


#IMPLIED 




amend-date 


NUMBER 


#IMPLIED 


5 


amend-les 


IDREF 


#IMPLIED 



< 



The insert-date attribute should be used to insert the date YYYYMMDD that the REG was inserted. 
The insert-leg should be used to insert the ID of the legislation that inserted the REG. 
10 The repeal-date attribute should be used to insert the date YYYYMMDD that the REG was 

repealed. The repeal-leg should be used to insert the ID of the legislation that repealed the REG. 
The amend-date attribute should be used to insert the date YYYYMMDD that the REG was 
amended. The amend-leg should be used to insert the ID of the legislation that amended the 
REG. 

15 The title gets marked up as Level "Heading Level 1 ". The period between the insert-date and the 
repeal-date or amend-date {that is the period during which the above element was in force) gets 
marked up as follows: 

The Folio Views markup used is Groups. See the manual for explanations. We will use three 
kinds of groups: Inforce-vvw. Inforce-vvvv-mm and Inforce-ww-mm-dd (vwv can be any year. 

20 mm can be any month from 1-12 and dd can be any day from 1-31). If the element was valid 
throughout a year vwv. the element becomes a member of the Inforce-ww group. If the element 
was valid only for some months within a year, it becomes a member of the relevant Inforce-ww- 
mm groups. If the element was only valid for some days within a month, the element becomes a 
member of the relevant Inforce-ww-mm-dd groups. Example: 

25 If the element was valid from 1/7/94 to 7/4/96. then the element belongs to the following groups: 
lnforce-94-07. In force- 94-08. lnforce-94-09. lnforce-94-10, lnforce-94-1 1 . lnforce-94-12. Inforce- 
95. lnforce-96-01. lnforce-96-02. lnforce-96-03. lnforce-96-04-01 . lnforce-96-04-02. lnforce-96-04- 
03. lnforce-96-04-04. lnforce-96-04-05. lnforce-96-04-06 and lnforce-96-04-07. 
Note that the element is not part of the lnforce-94 group because the element wasn't in force 

30 throughout of 1994, Nor is the element part of the lnforce-96-04 group because the element 
wasn't in force throughout April 1996. 

If the enduser wants to search for all elements that are valid as of a particular date then the 
enduser can enter that date in a Query Template in the form DD/MM/YYYY. The Query Template 
then searches the Folio Views infobase for all elements that belong to the groups Inforce-vvw. 
35 Inforce-ww-mm and Inforce-ww-mm-dd. 

ACT DTD ELEMENTS 

ACT 

This is the root element of the dtd for an Act. Its definition is : 

< ! ELEMENT act - - (title, notes?, provisions?, (preamble | long- title)?, (section* | chapter* |part+ |sub+)*, 
40 schedule*)> 
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<!ATTLIST act id ID #REOUIRED 



date CDATA #IMPLIED 



insert-date 


NUMBER 


#IMPLIED 


insert-leg 


IDREF 


#IMPLIED 


repeal-date 


NUMBER 


#IMPLIED 


repeal-lee 


IDREF 


#IMPLIED 


amend-date 


NUMBER 


#IMPLIED 


amend-lee 


IDREF 


#IMPLIED 



< 

10 That is, it contains a required title element, followed by optional notes, provisions, and preamble and either 
one or more reg, order, rule, section, chapter or part elements. It has a required id attribute and implied date 
attribute 

The insert-date attribute should be used to insert the date YYYYMMDD that the ACT was inserted. The 
insert-leg should be used to insert the ID of the legislation that inserted the ACT. 
15 The repeal-date attribute should be used to insert the date YYYYMMDD that the ACT was repealed. The 
repeal-leg should be used to insert the ID of the legislation that repealed the ACT. 

The amend-date attribute should be used to insert the date YYYYMMDD that the ACT was amended. The 

amend-leg should be used to insert the ID of the legislation that amended the ACT. 

Examples 

20 1979 No. 141 The charge to income tax 

<act lbl="14r ID="CWACT-19790141-TXT-0"> 
<title>1979 No. 141 The charge to income tax</> 
1979 No. 141 The charge to income tax*l* 
<act lbl="14r ID= n CWACT- 19790 14 l-TXT-0"> 
25 <title>1979 No. 141 The charge to income tax<noteref 
ref= "CWACT- 19790141 -note- 1" ></> 

The noteref gets marked up as a popup link. The text of the note becomes the text within the popup link. 

Treated the same as Reg DTD Elements. See there for details. 

30 COMMON ELEMENTS 

PART 

< ! ELEMENT part - - (title, (%plevel;)*, 
(chapter+ | division+ [ section*)*, notes?) 

< ! ATTLIST part id ID #REOUIRED 
35 lbl CDATA #IMPLIED 



insert-date 


NUMBER 


#IMPLIED 


insert- leg 


IDREF 


#IMPLIED 


repeal -date 


NUMBER 


#IMPLIED 


repeal-lee 


IDREF 


#IMPLIED 


amend-date 


NUMBER 


#IM PLIED 


amend-leg 


IDREF 


#IMPLIED 
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</list> 
</li> 
</list> 
</section> 

Convert list and li items back to the original look in Folio Views, ie to 

1. Fred... 

1. (1) This is ... 

Cross references 

AH cross references point directly to a target by providing the id of the target as the value of an 
attribute of the xref element. For details of the format of cross reference identifier strings, see the 
description of the xref element below. 

Ail IP's are marked unchanged as Jump Destinations (JD's). 
<SECTION 1D="CWACT-1 99501 04-SEC-1" LBL="1"> 
becomes: 

<JD:" ="CWACT- 1 99501 04-SEC- 1 "> 



REGS DTD ELEMENT 

REGS 

This is the root element of the Regulations. Its definition is : 
< ! ELEMENT regs - - (title, header?, reg+) > 

That is. it contains a reouired title element, followed by an optional header element followed by 1 
or more act element. 
Not translated 



ACTS DTD ELEMENT 

ACTS 

This is the root element of the Acts. Its definition is 

< ! (ELEMENT acts - - (title, header?, act+) > 

That is. it contains a reouired title element, followed by an optional header element followed by 1 
or more act element. 
Not translated 

REG DTD ELEMENTS 

REG 

This is the root element of the dtd for a Regulation. Its definition is: 

< ! ELEMENT reg - - (title, notes?, provisions?, (preamble [ long-title)?, 
( (order+ | (section | schedule)* | chapter* [ part+) , schedule*) ) > 

< ! ATTLIST reg id ID #REOUIRED 

IbJ CDATA #REOUIRED 

insert-date NUMBER #IMPLIED 



91 



> 

The insert-date attribute should be used to insert the date YYYYMMDD that the PART was 
inserted. The insert-lea should be used to insert the ID of the legislation that inserted the PART. 
The repeal-date attribute should be used to insert the date YYYYMMDD that the PART was 
5 repealed. The repeal-lea should be used to insert the ID of the legislation that repealed the PART. 
The amend-date attribute should be used to insert the date YYYYMMDD that the PART was 
amended. The amend-lea should be used to insert the ID of the legislation that amended the 
PART. 
Example 

10 <PART lbl=T' ID="CWACT-1 979014 l-PT-r'> 
<title></title> 

The title gets' marked up as Level "Heading Level 2". Dates get treated the same way as in Regs 
DTD) Elements. See there for details. 
15 ORDER 

<(ELEMENT order - - (title, 

(division | section | part | schedule) +) > 

<!ATTLIST order id ID #REOUIREP 

Ibl CDATA #/IMPLIED 

20 insert-date NUMBER #IMPLIED 



insert-leg IDREF #IMPLIED 





repeal-date 


NUMBER 


#IMPLIED 




repeal-leg 


IDREF 


#IMPLIED 




amend-date 


NUMBER 


#IMPLIED 


25 


amend-leg 


IDREF 


#IMPLIED 



> 



The insert-date attribute should be used to insert the date YYYYMMDD that the ORDER was 
inserted. The insert-leg should be used to insert the ID of the legislation that inserted the ORDER. 
The repeal-date attribute should be used to insert the date YYYYMMDD that the ORDER was 
30 repealed. The repeal-leg should be used to insert the ID of the legislation that repealed the 
ORDER. 

The amend-date attribute should be used to insert the date YYYYMMDD that the ORDER was 
amended. The amend-leg should be used to insert the ID of the legislation that amended the 
ORDER. 
35 Example 

1 979 No. 1 40 FEDERAL COURT RULES - ORDER 3< 

ORDER 3< 

TIME< 

m. 

40 $$A 
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1979 No. 140 FEDERAL COURT RULES - RULE 1< 

<ORDER lbl="3" ID="CWACT-19790140-QRD-3"> 
<title>TIME</title> 

<section tvpe^'rule" lbl= w l" ID="CWACT-19790l40-ORD-3. 1 "> 
5 The title gets marked up as Level "Heading Level 2". Dates get treated the same way as in Regs 
DTD Elements. See there for details. 
DIVISION 

<(ELEMENT division - - (title, Csub-division+ | section*)) 
> 

10 <(ATTLIST division id ID #/REOUIRED 
Ibl CDATA #IMPLIED 



insert-date NUMBER #IMPLIED 



insert-leg 


IDREF 


#IMPLIED 


repeal-date 


NUMBER 


#IMPLIED 


repeal-leg 


IDREF 


#IMPLIED 


amend-date 


NUMBER 


#IMPLIED 


amend-lee 


IDREF 


#IMPLIED 



> 

The insert-date attribute should be used to insert the date YYYYMMDD that the DIVISION was 
20 inserted. The insert-lea should be used to insert the ID of the legislation that inserted the 
DIVISION. 

The repeal-date attribute should be used to insert the date YYYYMMDD that the DIVISION was 
repealed. The repeal-leg should be used to insert the ID of the legislation that repealed the 
DIVISION. 

25 The amend-date attribute should be used to insert the date YYYYMMDD that the DIVISION was 
amended. The amend-leg should be used to insert the ID of the legislation that amended the 
DIVISION. 
Example 

1979 No. 140 FEDERAL COURT RULES - DIVISION 1< 

30 Division 1-Generak 

$$T 
$$A 

1 979 No. 1 40 FEDERAL COURT RULES - RULE 1 < 
35 Cases for service of originating process< 

<DIVISION lbl=T ID="CWACT-I 97901 40-DIV-i> 
<title>Generak/title> 

<RULE lbl="1" ID="CWACT-I 97901 40-DIV-1 .1 "> 
<title> Cases for service of originating process </title> 
40 The title gets marked up as Level "Heading Level 3". Dates get treated the same way as in Regs 
DTD Elements. See there for details. 
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SUB-DIVISION 



<!ELEMENT sub-division - - (title, section+) > 

<!ATTLIST sub-division id ID #REOUIRED 





Ibl CDATA 


#IMPLIED 




5 


insert-date 


NUMBER 


#IMPLIED 




insert-leg 


IDREF 


#IMPLIED 




repeal date 


NUMBER 


#IMPLIED 




repeal-lea 


IDREF 


#IMPLIED 




amend-date 


NUMBER 


#IMPLIED 


10 


amend-leg 


IDREF 


#IMPLIED 



> 

The insert-date attribute should be used to insert the date YYYYMMDD that the SUB-DIVISION 
was inserted. The insert-leq should be used to insert the ID of the legislation that inserted the 
SUB-DIVISION. 

15 The repeal-date attribute should be used to insert the date YYYYMMDD that the SUB-DIVISION 
was repealed. The repeal-lea should be used to insert the ID of the legislation that repealed the 
SUB-DIVISION. 

The amend-date attribute should be used to insert the date YYYYMMDD that the SUB-DIVISION 
was amended. The amend-leg should be used to insert the ID of the legislation that amended the 
20 SUB-DIVISION. 

The title gets marked up with a Paragraph Style (see Folio Views Infobase Production Kit Manual 
for details) 'Subdivision'. Dates get treated the same way as in Regs DTD Elements. See there for 
details. 

PROVISIONS 

25 <!ELEMENT provisions - - (title. tblbllO > 

Example 
$$NTABLE 

TABLE OF PRQVISIONS< 

$$P 
30 Order< 
$$P 

1 . Preliminary< 

$$P 

2. Sittings and Vacation< 

35 <PROVISIONS> 

<TITLE>T A B LE OF PROVISIONS> 
<TBLBLK> 

</TBLBLK> 
40 </PROVISIONS> 
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Provisions get ignored. The Table of Provisions sets generated bv the conversion program from the 
followine Elements: Part, Chapter. Order. Division. Subdivision and Section. The generated Table of 
Provisions is stored iust before the first Part. Chapter. Order. Division. Subdivision and Section. 
CHAPTER 

5 <! ELEMENT chapter -- (title. %plevel:)*. 
(part+ | section+ | article+)?)> 

<!ATTLIST chapter id ID #REOUIRED 



lbl CDATA #IMPLIED 





insert-date 


NUMBER 


#IMPLIED 


10 


insert-leg 


IDREF 


#IMPLIED 




repeal-date 


NUMBER 


#IMPLIED 




repeal-leg 


IDREF 


#IMPLIED 




amend-date 


NUMBER 


#IMPLIED 




amend-lee 


IDREF 


#IMPLIED 



15 > 

The insert-date attribute should be used to insert the date YYYYMMDD that the CHAPTER was 
inserted. The insert-lea should be used to insert the ID of the legislation that inserted the 
CHAPTER 

The repeal-date attribute should be used to insert the date YYYYMMDD that the CHAPTER was 
20 repealed. The repeal-leg should be used to insert the ID of the legislation that repealed the 
CHAPTER. 

The amend-date attribute should be used to insert the date YYYYMMDD that the CHAPTER was 
amended. The amend-lea should be used to insert the ID of the legislation that amended the 
CHAPTER. 

25 The title gets marked up as Level "Heading Level 2". Dates get treated the same way as in Regs 
DTD Elements. See there for details. 
SECTION 

This is a sub element of a Regulation. Its definition is: 

<!ELEMENT section (title, (%unstruct-cont;))> 

30 <!ATTLIST section id ID #REOUIRED 

lbl CDATA #/IMPLIED 

insert-date NUMBER #IMPLIED 



insert-leg IDREF #IMPLIED 





repeal-date 


NUMBER 


#IMPLIED 


35 


repeal-lee 


IDREF 


#IMPLIED 




amend-date 


NUMBER 


#IMPLIED 




amend-leg 


IDREF 


#IMPLIED 



> 



That is. it contains a reouired title element, followed bv unstructured content. It has a reguired lbl 
40 attribute and a required id attribute. 
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The insert-date attribute should be used to insert the date YYYYMMDD that the SECTION was 



inserted. The insert-leg should be used to insert the ID of the legislation that inserted the 
SECTION. 

The reoeal-date attribute should be used to insert the date YYYYMMDD that the SECTION was 
5 repealed. The repeal-lea should be used to insert the ID of the legislation that repealed the 
SECTION. 

The amend-date attribute should be used to insert the date YYYYMMDD that the SECTION was 
amended. The amend-lea should be used to insert the ID of the legislation that amended the 
SECTION. 
10 Examples 

1979 No. 141 The charge to income tax - SECT. 1 
Income Tax 

1979 No. 141 The charge to income tax - REG 2 
Tax 

15 3. Income tax shall be charged. . . 

<section lbl="l" id=XWACT-1979141-SEC-l"> 
<title>Income tax</> 

<section type = "reg" lbl = "2" id = CWACT 1979 141 -SEC- 
1.2" ><title>Tax</title> 
20 <p>Income tax shall be charged. . .</> 

The title gets marked up as Level "Heading Level 4". Dates gets treated the same way as in Reos 

DTD Elements. See there for details. 

SCHEDULE 

This is a sub element of a Regulation. Its definition is: 

25 <! (ELEMENT schedule - - (title?. (%-unstruct-cont:)b> 

<!ATTLIST schedule id ID #/REOUIRED 

lbl CDATA #IMPLIED 

insert-date NUMBER #IMPLIED 



insert-leg IDREF #IMPLIED 



30 


repeal -date 


NUMBER 


#IMPLIED 




repeal-leg 


IDREF 


#IMPLIED 




amend-date 


NUMBER 


#IMPLIED 




amend-Ies 


IDREF 


#IMPLIED 



> 

35 That is. it contains a reouired title element, followed bv unstructured content. It has a required Ibl 
attribute and a reouired id attribute. 

The insert-date attribute should be used to insert the date YYYYMMDD that the SCHEDULE was 
inserted. The insert-leg should be used to insert the ID of the legislation that inserted the 
SCHEDULE. 
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The repeal-date attribute should be used to insert the date YYYYMMDD that the SCHEDULE was 
repealed. The repeal-lea should be used to insert the ID of the legislation that repealed the 
SCHEDULE. 

The amend-date attribute should be used to insert the date YYYYMMDD that the SCHEDULE was 
5 amended. The amend-lea should be used to insert the ID of the legislation that amended the 
SCHEDULE. 
Examples 

1979 No. 141 The charge to income tax - SCHEDULE 1 
Income Tax 

10 _L Income tax shall be charged... 

<schedule Ibl = "1" id="CWACT-l 97914 1-SCH-1"> 

<title>Income tax</> 

<p>Income tax shall be charged ... </>. 

The title gets marked up as Level "Heading Level 2". Dates get treated the same way as in Regs 
15 DTD Elements. See there for details. 
FORM 

<! ELEMENT form - - (title, formreg, front, back?) > 

<!ATTLIST form %reqlbl: 

%reqid;> 

20 Each form has a title, regulation, a front and an optional back. Each has a required Ibl attribute 
and a required ID. 
Example 
FORM A< 

Regulation 7< 

25 (Front of Form)< 

COMMONWEALTH OF AUSTRALIA< 

Trade Practices Act 1974-Sub-section 88 (1)< 

EXCLUSIONARY PROVISIONS:< 

APPLICATION FOR AUTHORIZATION< 

30 To the Trade Practices Commission: Application is hereby made under sub-section 88 (1 ) of the 

Trade 

(Back of Form)< 

DIRECTIONS< 

1 . Where there is insufficient space on this form to furnish the required information, the 
35 information is to be shown on separate sheets, numbered consecutively and signed by or on 
behalf of the applicant. 

<FORM lbl="a" ID="CWACT-I9790141-FORM-A"> 
<FORMREG>Requlation 7</FORMREG> 
<FRONT> 
40 <AS IS> 

COMMONWEALTH OF AUSTRALIA< 
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Trade Practices Act 1974-Sub-section 88 (1)< 

EXCLUSIONARY PROVISIONS:< 

APPLICATION FOR AUTHORIZATIONk 

To the Trade Practices Commission: Application is hereby made under sub-section 88 (1) of the 
5 Trade 
</ASIS> 
</FRONT> 
<BACK> 
<ASIS> 
10 DIRECTIONS< 

1 . Where there is insufficient space on this form to furnish the required information, the 
information is to be shown on separate sheets, numbered consecutively and signed by or on 
behalf of the applicant. 
</ASIS> 
15 </BACK> 
</FORM> 

Forms get marked up with a Paragraph Style 'Forms'. The markup of 'Front' and 'Back' gets 
inserted as hidden text (hidden text is visible on the screen but doesn't show when the Form gets 
printed. 

20 FORM ELEMENTS 

FORMREG 

< 'ELEMENT formreg -- (#PCDATA) > 

see above example 
FRONT 

25 <! ELEMENT front -- (asis) > 

see above example 
BACK 

<! ELEMENT back (asis) > 

see above example 
30 ASIS 

<! ELEMENT asis - - (#PCDATA) > 

date is displayed as-is 
see above example 

HEADER ELEMENTS 

35 HEADER 

< [ELEMENT header (scope?, updated?) > 

SCOPE 

< [ELEMENT scope (%text;) > 

UPDATED 

40 <!ELEMENT updated -- (%text:) > 

NOTE ELEMENTS 
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NOTES 

<! ELEMENT notes - Q (note+) > 

List of notes at the start of an act 
NOTE 

5 <!ELEMENT note (%/plevel;) > 

<!ATTLIST note id ID #REOUIRED> 

A single note 

Forms get marked up with a Paragraph Style 'Forms'. The markup of 'Front' and 'Back' gets 
inserted as hidden text (hidden text is visible on the screen but doesn't show when the Form gets 
10 printed. 

STRUCTURAL ELEMENTS 

TITLE 

A generic title, which may occur in several different contexts. 
Covered in Acts DTD Elements. Regs DTD Elements and so on. 

15 INLINE ELEMENTS 

BOLD 

Used to mark any inline text which is set in a bold face other than a title or a label. It may contain 
text or any inline elements other than <bold>. 
It has no attributes. 
20 ILEQN 

An inline eguation. This is a mathematical eguation which is embedded in a line of text characters 

or other inline elements. See the attached description of eguations for further details. 

ITAL 

Used to mark any inline text which is set in a italic face other than a title or a label. It may contain 
25 text or any inline elements other than <italic>. 
It has no attributes. 
QUOTE 

A sequence of text characters or inline elements surrounded by single or double paired Quotation 
marks. The quotation mark characters must not be entered as text characters or entity references 
30 as thev will be generated automatically. 
SUBSCR 

A Subscript (inferior). 
SUPER 

A superscript (superior). 
35 Brought over from SGML to Folio Views with no changes. 

CROSS REFERENCES 

NOTEREF 

A reference to a NOTE element normally used in a TITLE element 
Implemented as a popup link. 
40 TEMPREF 
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A reference to a piece of legislation where the ID is not known. The tempref element will 
converted to an XREF element at a later date (when the ID is known). 
Not converted. 
RNGREF 

5 A cross reference to a sequential range of targets, e.g. see Sections 3 to 7. 

It has two required attributes, startref and endref. Startref is the id of the first of the targets 
referenced and endref is the id of the last target referenced. For a description of id strings, see the 
description of the xref element- 
Concerted as a Query Link. 
10 XREF 

A cross reference to a single target. It has a single attribute, ref. which must contain the id string 
of the target of the reference. Ids are not being entered on elements during keying, but will be 
generated automatically from the Ibl attribute of elements. 

However, for xrefs it is necessary to work out what the id string of the target will be. 
15 The format of id strings is described below: 
Converted as a iumolink. 
ID Strings 

Cross references to sections of Acts and Act Schedules should be marked up using the xref 
element as described above. 

Id strings are made up of four sequential fields separated bv a "-" (dash) character 
as follows 

field 1 -field2-field3-field4 

field 1 is the type of document which is being referenced. The current valid value is ACT. 
25 field2 is an abbreviated form of the year and number of the Act, e.g. 1 9880001 is 1 988 No. 1 . 

field3 identifies the type of object being referenced. Valid values are: 

ORD order 

DIV division 

SCH schedule in an Act 
30 SEC section in an Act 

CH chapter in an Act 

PT part in an Act 

NOTEa note 

field4 is the identifier of the element being referenced, which is formed bv concatenating the 
35 values of the Ibl attributes of the referenced element and its ancestor elements, separated bv a"." 
(point) character, e.g. 1 or 1 .1 or 1 .1 .a or 1 .1 .a.iv 
Examples 

<section lbl=T'> <!- id is ACT- 1 9790 141-SEC-l -> 
<title>The charge to income tax.</> 
40 <list> 

<li lbl= M r> 
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<p>Income tax shall be charged. . .</> 
Implemented us iumpdestination. 

BLOCK LEVEL ELEMENTS 

DPEQN 

5 A display equation. This is a mathematical equation which is set on one or more lines bv itself. 
See the attached description of equations for further details. 
It has no attributes. 
It has no attributes. 
LIST 

10 A list of related lines of text which are not sub, s-sub or ss-sub elements. 
U 

An item in a list. This is a single line of text within a list. 

It has a single attribute, marker, which has allowed values of bullet, dash or none, with a default of 
none. If a marker character precedes the list item then the relevant value should be entered for 
15 the attribute. The marker character should not be entered as text. If any marker character other 
than a bullet or dash is found, contact SGMLSE for a change to the DTD. 
P 

A single line of text. 
BLOCKQUOTE 

20 A non-inline guote. The quotation mark characters must not be entered as text characters or entity 
references as thev will be generated automatically 
TBLBLK 

A container element for a table which has a title. It contains a reguired title element followed bv a 
single table. 
25 It has no attributes. 

The above elements get implemented either without conversion or using paragraph styles. 

TABLE ELEMENTS 

General 

Arbortext tables expressed in tagged ASCII form must follow this basic structure: 
30 <table> 

<rowrule> 
for each row 

I 

<tablerow> 

35 <cell rule> 

for each column 

L 

<tablecell>text</tablecell> 

<cellrule> 

40 L 

</tablerow> 
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<rowrule> 

1 

</table> 
TABLE 

5 The <table> tag has three required attributes. They must be specified correctly or the table will not 
be handled properly. 

ncols=NUMBER The number of columns in the table. This value MUST agree with the number 
of columns expressed by the required cwl attribute. 
. Wdm=(25|50l75l100) The numbers indicate the width of the table as a percentage of the page 
10 width. 

cwl=LIST where LIST is a list of integers each separated by a colon. Each integer represents 

the relative width of a column. 

Example 

A four column table which is the full width of the page. The second and third columns are twice 
15 the width of the first column, and the fourth column is three times the width of the first: 

<table ncols="4" wdm="100" cwl=" 1 :2:2:3"> 
on eguivalentlv. 

<table ncols="4" wdm="100" cwl="5: 10: 10: 15"> 
CELLRULE 

20 Empty element. Specifies a vertical rule. It has a single attribute, rtv. which specifies the type of 

rule. Valid values for rtv are: 

"." (point)for a blank rule. 

(dash)for a single rule. 

(equals) for a double rule. 

25 "+" (plus) for a bold rule. 

Example 

<cellrule rty="."> 

for a blank rule, or 

<cellrule rtv="-"> 
30 for a single rule. 

ROWRULE 

Empty element. Specifies a sequence of horizontal rules, one per cell in the row. It has a single 
attribute, rtl. which is a colon-delimited list of rule type specifiers. There must be one rule type 
specifier for each cell in the row. The valid specifiers are as for cellrule above. 
35 Example 

For a four-column table 

<rowrule rtl="-:. :.:-"> 

would draw a horizontal rule above cells one and four. 
TABLEROW 

40 Specifies a row in the table. It has a single attribute, hdr. which specifies whether or not the row is 
a header row in a table which will be repeated over page breaks. The only valid value is "1 "(one). 
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which indicates that the row is a header row. An omitted value for hdr indicates that the row is not 
a header row. A value is only valid on the first <tablerow> in the table- 
Example 

<tablerow hdr="l"> 

5 indicates that the row is a header row (iff the <tablerow> is the first in the table, else it will generate 
an error). 
<tablerow> 

indicates that the row is not a header row if the <tablerow> is the first in the table. 
TABLECELL 

10 Indicates a cell in a row in a table. It has four optional attributes: 

chj= (b | 1 |r|c) Horizontal justification for that cell. 
b for both right and left justified, 



1 


for flush left. 


r 


for flush right. 


15 c 


for centred. 


Default: 


left justified 



30 



35 



cvj = (t|c | b) Vertical justification for that cell. 

t for top justified, 

c for centred, or 

20 b for bottom justified. 

Default: top justified 

spn= INTEGER For horizontally spanned columns. VAL is a whole number representing how 
many columns are spanned. Note that for horizontal spans, the text appears in the LEFTMOST 
cell in the span, and all other cells in the span should be void of text. 
25 Default: I 

vspn=INTEGER For vertically spanned rows. VAL is a whole number representing how many 



and all other cells in the span should 


be void of text. 


Default: 1 




Arbortext table example 




Ifoo I fum I I 


i i i 


fee I 




I spanned I 


ugh I 


I I I 



<tbl> 

<table wdm="IOO" cwl="3:4:3"> 
40 <rowrule rtl="-:-:-"> 
<tablerow hdr="1"> 

105 



<cellrule rtv="-"> 
<tablecell>foo</tablecell> 
<ceHrule rtv="-"> 

<tablecell chi="c">fum</tablecell> 
5 <cellrule rtv="-"> 

<tablecell chi="r" cvi="b">fee</tablecell> 
<cellrule rtv"-"> 
</tablerow> 
. <rowrule rtl"-:-:-"> 



10 


<tablerow> 




<cellrule rtv="-"> 




<tablecell son="2" chi="c">spanned</tablecell> 




<cellrule rtv="-"> 




<tablecell chi="c">uah</tablecell> 


15 


<cellrule rty= ,, -"> 



</tablerow> 
<rowrule rtl="-:-:-"> 
</table> 
</tbl> 

20 Tables get converted to Microsoft Word tables and then converted into Folio Views. 

EQUATION ELEMENTS 

General 

This maths DTD is a subset of the Arbortext maths DTD, which itself is derived from the AAP 
maths DTD. 

25 In maths mode, all spaces are ignored (except in a <phr> element as described below). Correct 
spacing is handled automatically. 

All alphabetical characters and symbols are treated as variables and set in italic face, unless they 
occur within <phr>. <rm> or <rf> elements. 

AH numeric characters and operators are set in roman face, unless they occur within an <it> 
30 element. 

Greek symbols should be entered using the <g> element rather than entity references. E.g. 
<g>a</g> produces alpha. <g>b</g> beta, etc. Any entity references for Greek characters which 
appear in eouations will be flagged as errors by the parsing program. 
B 

35 Bold text in an eouation. 
DE 

Denominator of a fraction. 
F 

Inline eouation. 
40 FD 

Display eouation. 
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FEN 

Fence. A pair of bracketed delimiters. The attribute Id (left post) defines the type of the left 
delimiter as below, and the following element rp (right post) defines the type of the right delimiter. 

<!ATTLIST fen lp (parlsablcublanslvb) vb 

par left parenthesis £. 

sqb left square bracket [ 

cub left curly brace {_ 

ang left angle bracket < 

vb left vertical bar [ 

— > 
FR 

Fraction. 
G 

Greek character or characters. Valid characters are: 
char eguivalent entity 



a 


aloha 


b 


beta 


c 


chi 


d 


delta 


D 


Delta 


e 


epsilon 


3 


eosiv 


4 


phiv 


f 


phis 


F 


Phi 


a 


gamma 


G 


Gamma 


h 


eta 


i iota 


i 


thetav 


k 


kappa 


1 lambda 


L 


Lambda 


m 


mu 


n 


nu 


P 


P' 


2 


piv 


P 


Pi 


q 


thetas 


Q 


Theta 


r 


rho 
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10 



s 


siama 


s 


Siama 


9 


rhov 


t 


tau 


u 


uDsilon 


u 


UDsilon 


v 


siamav 


w 


omeaa 


W 


Omeaa 

V*^ 1 1 1 \mf V4 


x 


xi 


X 


Xi 


y 


osi 


Y 


Psi 


2 


zeta 



15 INF 

Inferior. Subscript in an equation. 
IT 

Italic text in an equation. 
NU 

20 Numerator of a fraction. 
OVL 
Overline. 
PHR 

Phrase. In a phrase all characters are set in roman face and keyed space characters are 
25 preserved. A phrase is essentially a temporary escape out of maths mode back into normal text 
mode. 
RAD 

Radical or root. Contains a radicand (<rcd>). which is the constructs which appear beneath the 
top horizontal ban and an optional radix (rdx). which is the power of the root (e.g. square, cube. 4. 
30 etc.). 
RCP 

Radicand. The content of a root construct. 
RDX 

Radix. The power of a root. 
35 RF 

Roman Function. A function name set in roman face, such as loo, sin, cos, lim, arq. etc. It differs 
from the <rm> element in that preceding and following space characters are generated to separate 
it from surrounding characters. 
RM 

40 Roman face. Used to force an alpha character to be displayed in normal face rather than be 
treated as a variable and displayed in italic face. 
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RP 

Right delimiter of a fence. It has a single attribute, post, which defines the type of the delimiter. 
Valid values are the same as for the lp attribute of the <fen> element, except that thev specify the 
right hand match for the relevant left post, 
5 SUP 

Superior. A superscript in an eguation. 
UNL 

Underline. 

Arbortext equation examples 

10 ...by multiplying by the fraction - 

A 

B 

where - 

<p>. . . by multiplying by the fraction -</> 
15 <dpeqn>< frxnuxrm>A</ ></ ><dexrm>B</ ></ ></></> 
<p>where -</p> 

... by the formula - 

gross taxable income 

20 net assets 



<p>. . . by the formula -</> 

<dpeqn>< frxnuxphr>gross taxable income</></xde><phr>net 
assets</ ></></ ></> 

25 Equations get converted to Microsoft Word equations and then converted into Folio Views. 
Alternatively equations get converted to images and added to Folio Views as images. 
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<!SGML "ISO 8879: 1 986" 



APPENDIX E 



ArborText's default SGML declaration, modified to allow longer id/idref s, and to 
5 use a number of special characters within them. 

CHARSET 

B ASESET "ISO 646- 1 983//CHARSET 
International Reference Version qRVV/ESC 2/5 4/0" 
10 DESCSET 

0 9 UNUSED 

9 2 9 

11 2 UNUSED 





13 


1 13 


15 


14 


18 UNUSED 




32 


95 32 




127 


1 UNUSED 



128 128 "High-order characters" 



20 



25 



30 



35 



CAPACITY SGMLREF 




TOTALCAP 


200000 


ENTCAP 


35000 


ENTCHCAP 


35000 


ELEMCAP 


35000 


GRPCAP 


150000 


EXGRPCAP 


35000 


EXNMCAP 


35000 


ATTCAP 


50000 


ATTCFICAP 


35000 


AVGRPCAP 


35000 


NOTCAP 


35000 


NOTCHCAP 


35000 


IDCAP 


35000 


IDREFCAP 


35000 


MAPCAP 


35000 


LKSETCAP 


35000 


LKNMCAP 


35000 



SCOPE DOCUMENT 

40 SYNTAX 

SHUNCHARO 1 2 3 4 5 6 7 8 9 10 1 1 12 13 14 15 16 17 

18 19 20 21 22 23 24 25 26 27 28 29 30 31 127 

B ASESET "ISO 646-1983//CHARSET 

International Reference Version qRVV/ESC 2/5 4/0" 
45 DESCSET 0 128 0 

128 128 "High-order characters" 

FUNCTION RE 13 
RS 10 



SPACE 32 

50 TAB SEPCHAR 9 

NAMING LCNMSTRT " " 
UCNMSTRT " " 
LCNMCHAR "-./IT 
UCNMCHAR "-./IT 
55 NAMECASE GENERAL YES 
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ENTITY NO 



DELIM GENERAL SGMLREF 
SHQRTREF SGMLREF 



10 



20 



NAMES SGMLREF 


OUANTITY SGMLREF 




ATTCNT 


100 


ATTSPLEN 960 




BSEOLEN 


960 


DTAGLEN 


16 


DTEMPLEN 16 




ENTLVL 


16 


GRPCNT 


100 


GRPGTCNT 96 




GRPLVL 


16 


LITLEN 


NAMELEN 


64 


NORMSEP 


2 


PILEN 


1024 


TAGLEN 


960 


TAGLVL 


24 



15 LITLEN 800 



FEATURES 

MINIMIZE DAT AT AG NO OMITTAG YES RANK NO SHQRTTAG 
YES 

25 LINK SIMPLE NO IMPLICIT NO EXPLICIT NO 

OTHER CONCUR NO SUBDOC NO FORMAL YES 

APPINFO NONE> 



<!DOCTYPE legislation 
30 £ 

<!— 



DTD for Scantext/Abha Legislation - (C) Turn-Key Systems 1997 
History: 



35 1997-10-13: fix hist at beginning of regs 

1997-10-07: restore <target> tag 



1997-10-02: enhanced support for regulations (hist unconv etc) 



40 

<!— useful characters such as — — > 

< 'ENTITY % ISOpub public "ISO 8879- 1 986//ENTITIES Publish ing//EN"> 
%ISQpub; 



45 <!- PARAMETER ENTITIES USED TO SIMPLIFY DTD MARKUP -> 
<!entitv % major 

"schedule|intcon|article|annex|clause|chapter | part|division|subdivn | section|subs eclreglsubreg" 



— major levels --> 



50 



<!entitv % minor "defnlpara | subparllsubpar2|subpar3|subpar4[point" 
— minor levels — > 
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<!entitv % secreg "section | reg" 

— used where either sections or regs are appropriate — > 

5 <!entity % level "%maior: | %minor:" 
— all levels — > 

< entity % refs "term I l.ref | h.ref ' 

— references which can be found in normal text — > 

<!entitv % raw "(rawtext | rawtable | unconverted)*" 
10 — material such as forms which remains as raw text — > 

<!entitv % effect "sc" 

— typographical effects (more to be added later) --> 

<!entitv % text "(%refs: | %effect: |#PCDATA)*" 
— normal text (including refs defined above) — > 

15 <!entitv % hnote "hist I note" 

— hist and note are temporarily interchangeable — > 

<!entitv % body "(p+ I repealed), (%hnote;)*" 
— body of a legislative element — > 

< !entitv % lev.id "((label, desc?) | (desc, label?))" 
20 — reversible level id — > 



<!- MASTER ELEMENT -> 

<!element legislation - - (act | regulations)* 

— Acts and Regs are currently supported — > 



25 



30 



<!- DEFINITIONS OF ACTS AND CONSTITUENT ELEMENTS --> 



<!element act 



- - (desc, (%hnote; | %raw;)*. 



longtitle, preamble?. 



(chapter-f | part+ | section*), 



Schedule*, hist*)> 

<!element longtitle - - (#PCDATA)> 
<!element preamble - - (p+) +(para)> 



35 



<!element regulations - - (desc, (%hnote; | %raw;)*, 
(chapter* | part* | reg+). 



schedule*, hist*)> 



40 



45 



50 



- MAJOR LEVELS -> 

element chapter - - (label, desc, (%hnote;)*, 

(((%secreg;)*, part*) | article+))> 
element part - - (label?, desc, hist*, 

(((%secreg;)*, division*) | (article+ | clause+)))> 



element division - - (label?, desc, (p | %hnote;)*, 



(((%secreg;)*, subdivn*) | clause+))> 
element subdivn - - (label?, desc, (%hnote;)*, 
((%secreg;)+ | clause+))> 



element section - - (%lev.id;, 

((subsec +, (modules [ module +)?) | repealed))> 



element subsec - - (%lev.id;, 

((p, (p I note)*, hist*) | (repealed, note*, hist*)))> 



element modules - - (%lev.id;, 
module+)> 



element module - - (%lev.id; 
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(submod + | repealed))> 

<!element submod - - (%lev.id:. 



((p, (p | %hnote: | method | tabloid)*) [ (repealed, (%hnote;)*)))> 



<!element reg - - (label?, desc, hist?, 



(subreg + [ repealed))> 



<!element subreg - - (label, desc?, hist'?. 



((p, (p | note)*, hist*) | (repealed, note*, hist*)))> 



<!- SCHEDULES. CONVENTIONS etc -> 
10 <!element schedule - - (label?, desc?, hist*. 



(chapter+ | part+ [ section+ item+ | p+ [ tabloid+ | intcon)?. 



%raw;)> 



<!element intcon - - (desc, preamble. 



(part+ | division+ | subdivn+ [ article+), annex*)> 



15 <!element annex - - (label?, desc, p*. 



(part* | division* | clause* | para*. 



<!element article - - (label, desc?) para*))> 



(division* | clause* | para*))> 



<?element clause - - (((label, desc?) | (desc, label)), p+)> 



20 <?element item - - (label?, desc?, %body;)> 



<!- DEFINITIONS AND MINOR LEVELS -> 
<?element defn - - (%bodv;)> 
<!element note - - (label?, p+)> 
25 <!element hist - - (label?, (p+ | raw;)) 



<!element point - - (p+)> 

<!element para - - (label?, %body;)> 
<!element subparl - - (label?, %body;)> 
30 <!element subpar2 - - (label?, %body;)> 
<!element subpar3 - - (label?, %bodv;)> 
<?element subpar4 - - (label?, %bodv;)> 

<!element method - - (%lev.id;, (p [ %hnote; | step)+)> 
35 <!element step - - (label, %bodv;)> 

<?- COMMON CONSTITUENT ELEMENTS -> 
<!element label - - (%text;) 

— chapter number, section number, etc. --> 

40 <!element desc - - (%text;) 

— chapter name, section name, etc. --> 

<!element term - - (%text;) 

-- defined term — > 

<!element repealed - o EMPTY 
45 — indicates that the enclosing level has been repealed — > 



<!element p - - (%minor | refs; | %effect [ tabloid I amend | target | #PCDATA)* 



— textual paragraph at any level — > 

<!-- UNCONVERTED MATERIAL -> 
50 <!element unconverted - - CD AT A 

— vet to be converted (eg, complex schedules) — > 

< [element rawtext - - CD ATA 

— unconverted text (eg. forms) — > 

<!element rawtable - - CD ATA 
55 — unconverted tables (eg. amended provisions) — > 
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<!-- CROSS-REFERENCES -> 

<!element l.ref - - (%text;) — legislation ref — > 

<!element h.ref - - (%text;) — history ref — > 

<!-- AMENDMENT MARKUP-> 

<!element amend - - (%refs I %effect | quote I #PCDATA)* 

— amendment = action + text — > 

<!element target - - (#PCDATA) 
— target of amendment — > 



10 <!element quote - - (label 1 desc I p | %level I %refs I %effect | #PCDATA)* 



quoted material — > 



<!- PSEUDO-TABLES -> 

<!element tabloid - - (label?, desc?, (head | row)+)> 
15 <!element head - - (celI+)> 
<!element row - - (cell+)> 
<!element cell - - (#PCDATA|p )*> 

<!- EFFECTS -> 
20 <!element sc - (#PCDATA) - small caps -> 



25 



30 



35 



40 



45 



50 



55 



<!-- ATTRIBUTE LISTS --> 



<!attlist act juris (cth | nsw | vie | qld | sa | wa [ tas | act | nt | imp) 



#REOUIRED - jurisdiction - 



year 



CDATA #REOUIRED - year assented - 



number 



CDATA #REOUIRED - act number - 



reps 



CDATA 



#IMPLIED - 2nd reading (HR) - 



senate 



CDATA 



#IMPLIED - 2nd reading (Sen) - 



assent 



CDATA 



#IMPLIED - assent date - 



cdate 



CDATA 



#IMPLIED -- commencement — > 



<!attlist regulations juris (cth | nsw | vie | qld | sa | wa | tas | act I nt | imp) 



#REOUIRED - jurisdiction - 



Year 


CDATA 


#REOUIRED -- year assented -- 


number 


CDATA #REOUIRED - act number 


reps 


CDATA 


#IMPLIED -- 2nd reading (HR) 


senate 


CDATA 


#IMPLIED 2nd reading (Sen) -- 


notified 


CDATA #IMPLIED -- notification date -- 


cdate 


CDATA 


#IMPLIED -- commencement 


<!attlist schedule id 


ID 


#IMPLIED -- legislation id -- 


cdate 


CDATA 


#IMPLIED ~ commencement — 


ref sec 


CDATA 


#IMPLIED — referring section --> 


<!attlist chapter id 


ID 


#IMPLIED -- legislation id -- 


cdate 


CDATA 


#IMPLIED — commencement 


<attlist part id 


ID 


#IMPLIED legislation id -- 


cdate 


CDATA 


#IMPLIED — commencement 


<!attlist division id 


ID 


#IMPLIED legislation id - 


cdate 


CDATA 


#IMPLIED — commencement 


<!attlist subdivn id 


ID 


#IMPLIED -- legislation id - 


cdate 


CDATA 


#IMPLIED — commencement 


<!attlist section id 


ID 


#IMPLIED - legislation id -- 


cdate 


CDATA 


#IMPLIED ~ commencement — > 


<attlist subsec id 


ID 


#IMPLIED -- legislation id -- 


cdate 


CDATA 


#IMPLIED — commencement — > 


<!attlist res id 


ID 


#IMPLIED - legislation id -- 


cdate 


CDATA 


#IMPLIED — commencement — > 


<!attlist subreg id 


ID 


#IMPLIED legislation id 


cdate 


CDATA 


#IMPLIED — commencement — > 


<!attlist l.ref ref 


IDREF 


#IMPLIED -- legislation idref --> 


<!attlist term id 


ID 


#IMPLIED - term id 
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Industrial Applicability 

It is apparent from the above that the arrangements described are applicable to the 
electronic publishing industry. 

The foregoing describes only some embodiments of the present invention, and 
5 modifications and/or changes can be made thereto without departing from the scope and 
spirit of the invention, the embodiments being illustrative and not restrictive. 
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1822. 
All 





Corporations Legislation with MALT f84 hits! 
Principal Acts 175 hits! 
Corporations Act 1989 f9 hits! 
Part 9: Jurisdiction and Procedure of Courts 



59. Enforcement of judgments etc 

Scope: 16 Oct 1995 onwards 

Wrh 1*07 fW I80S 

Versions Amendments 



Shift View 



(1 ) A judgment of the Federal Court, t he Family Court or a\co urt of the Capital Territory 
that is given, in whole or in part, in the H^flflHUHHH conferred by this Division, 
or by a law of a State that corresponds to this Division, is enforceable in the Capital 
Territory as if the judgment had been given by that court entirely in the exercise of the 
jurisdiction of that court apart from this Division or any such law. 

(2) Where: 

(a) a provision of a law of the Commonwealth or of the Capital Territory (not being 
a law in relation to the enforcement of judgments) refers to a thing done by the 
Federal Court, the Family Court, the Supreme Court of the Capital Territory or of 
a State, a State Family Court or a particular lower court of the Capital Territory 
or of a State; and _ / i%€f (SOG 




(b) that thing is done by another court in the 

this Division or a law of a State corresponding to this Division; 



conferred by 



the reference in that provision to the Federal Court, the Family Court, the Supreme Court 
of the Capital Territory or of that State, that State Family Court or that lower court, as the 
case may be, is taken as a reference to that other court. 



«5- 1815" 



405 J80S" 



4*0- 1810 



iSoc 
15£ 



16 Oct 1995 to 31 Dec 2001 : s 59 
► 01 Jan 1994 to 15 Oct 1995 : s 59 ^ 
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59. Enforcement of judgments etc 

Scope; until 15 Oct 1995 



MO- 



Versions Amendments 



Shift view 



(1 ) A judgment of the Federal Court, the Family Court or the Supreme Court of the 
Capital Territory that is given, in whole or in part, in the exercise of jurisdiction 
conferred by this Division, or by a law of a State that corresponds to this Division, is 
enforceable in the Capital Territory as if the judgment had been given by that Court 
entirely in the exercise of the jurisdiction of that Court apart from this Division or any 



(2) Where: 

(a) a provision of a law of the Commonwealth or of the Capital Territory (not being 
a law in relation to the enforcement of judgments) refers to a thing done by the 
Federal Court, the Family Court, the Supreme Court of the Capital Territory or of 
a State or a State Family Court; and 

(b) that thing is done by another court in the exercise of jurisdiction conferred by 
this Division or a law of a State corresponding to this Division; 

the reference in that provision to the Federal Court, the Family Court, the Supreme Court 
of the Capital Territory or of that State, that State Family Court, as the case may be, is 
taken as a reference to that other court. 



such law. 



Fig. 2r I ^ 



Zooo 



► Corporations Legislation Amdt Act 1994 (Cth): Sch 1. Pt 1. item 15 <n — 321 
Corporations Legislation Amdt Act 1994 (Cth): Sch 1, Pt 1, item 16 — * — 322 
Corporations Legislation Amdt Act 1994 (Ctrl): Sch 1. Pt 1. item 17 — L«~* 323 





Schedule 1, Part 1, Item 15 

Scope: amending provision 



Targets 



Shift view 



15. Subsection 59(1): 

(a) Omit the Supreme Court, substitute a court. 

(b) Omit that Court (wherever occurring), substitute that court. 
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Folio VIEWS - (MALT GST Commentary] 



MB* 




[GS10.10.3D] How is this commentary structured? Commentary created 1 July 2000 



[GS10.10.30J How is this commentary structured? 

Commentary created 1 July 2000 2Z(o5" 



To assist in understanding GST and its operation the core system without complexities is examined 
first. The less frequently encountered or special topics, that may only apply to a limited number of 
taxpayers, are then introduced in a manner that builds oh this basic understanding. 



The approach is to look at matters in the following order 

1 Administrative aspects of this basic system, such as returns, payments and adjustments. 

2 The concepts of GST-free or input taxed supplies (ie concessionary treated goods or 
services) and mixed situations requiring apportionment 

3 Special regimes, types of transactions or other concessions. 



/it ira 



ii 

mi 



IS 

if 

VAVr* 



Fig.SA- 22 At 



2.27Q 
570 



Folio VIEWS - [MALT GST Commentary] 




[GS10. 10.30] How is this commentary structured? Commentary updated 1 September 2000 



[GS10. 10.30] How is this commentary structured? 



Commentary updated 1 September 2000 



575- 



To assist in understanding GST and its operation the core system without complexities is examined 
first. The less frequently encountered or special topics, that may only apply to a limited number of 
taxpayers; are then introduced in a manner that builds on this basic understanding. 



The approach is to look at matters in the following order: 



1 

2 

3 
4 
5 



Administrative aspects of this basic system, such as returns, payments and adjustments. 

The concepts of GST-free or input taxed supplies (ie concessionally treated goods or 

services) and mixed situations requiring apportions 

Special regimes, types of transactions or other concessions. 

Imports and exports. 

Special rules for certain types of entities. 
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[GS10.10.30] Logical content of this commentary Commentary recreated 1 October 2000 
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[GS10. 10.30] Logical content of this commentary 



Commentary recreated 1 October 2000 



-585- 



To assist in understanding GST and its operation the core system without complexities is examined 
first. The less frequently encountered or special topics, that may only apply to a limited number of : 
taxpayers, are then introduced in a manner that builds on this basic understanding: j 



The approach is to look at matters in the following order: 

1 The basic GST system for transactions that are wholly within Australia, without the 
complications of GST-free or input taxed supplies. 

2 Administrative aspects of this basic system, such as returns, payments and adjustments. 

3 The concepts of GST-free or input taxed supplies (ie concessionally treated goods or 
services) and mixed situations requiring apportionment. 

4 Special regimes, types of transactions or other concessions. 

5 Imports and exports. 

6 Special rules for certain types of entities. 
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